-
GAMEPOD.hu
JavaScript != Java (A JavaScript nem összekeverendő a Javával, két különböző programozási nyelvről van szó!)
Új hozzászólás Aktív témák
-
-
Jim-Y
veterán
válasz martonx #5452 üzenetére
Felig meddig igazad van, a typeof az onmagaban broken es tipus vizsgalatra nem javallott. Egy dologra alkalmas, undefined vizsgalatra Bar en arra is inkabb explicitebb megoldast valasztanek pl
valami === void 0 de ez egyeni preferencia.Kb jQuery + underscore + lodash-bol osszeollozva
function isString(obj) {
return $.type(obj) === 'string';
}
function isNumber(obj) {
return exist(obj) && $.isNumeric(obj);
}
function isBoolean(obj) {
return obj === true || obj === false || $.type(obj) === 'boolean';
}
function isArray(obj) {
return exist(obj) && $.isArray(obj);
}
function isFunction(obj) {
return $.type(obj) === 'function';
}
function isDate(obj) {
return $.type(obj) === 'date';
}
function isRegExp(obj) {
return $.type(obj) === 'regexp';
}
function isError(obj) {
return toString.call(obj) === '[object Error]';
}
function isUndefined(obj) {
return obj === void 0;
}
function isNull(obj) {
return obj === null;
}
function isEmpty(obj) {
if (!exist(obj)) {
return true;
}
if (isNumber(obj) || isBoolean(obj) ) {
return false;
}
if (isArray(obj) || isString(obj) || toString.call(obj) === '[object Arguments]') {
return obj.length === 0;
}
return $.isEmptyObject(obj);
}
function exist(obj) {
return !isNull(obj) && !isUndefined(obj);
}[ Szerkesztve ]
-
Zedz
addikt
válasz slice14 #5458 üzenetére
Az undefined azt jelenti, hogy az adott változónak nincs értéke. Itt szépen leírják, hogy mire is kell gondolni.
Ha egy kicsit lejjebb görgetsz, akkor látni fogod, hogy az if(x === undefined) az igazából ugyan az, mintha azt vizsgálnád, hogy if(!x).
Ha érdekel a JS akkor szerintem megéri rászánni egy kis időt, és elolvasni ezt a könyvet.
-
j0k3r!
senior tag
"Ha egy kicsit lejjebb görgetsz, akkor látni fogod, hogy az if(x === undefined) az igazából ugyan az, mintha azt vizsgálnád, hogy if(!x)."
Ez nem igaz. Pl.:
var a = undefined;
var b = null;
var c = "";
var d = false;
var e = 0;
if(!a) console.log("a");
if(!b) console.log("b");
if(!c) console.log("c");
if(!d) console.log("d");
if(!e) console.log("e");(remélem nem gépeltem el a kódot)
some men just wanna watch the world burn...
-
martonx
veterán
válasz slice14 #5463 üzenetére
Azt kellene belátnod, hogy egy fórumból sosem fogsz megtanulni programozni. Egy-egy kérdésedre kapsz persze választ, és így tovább tudsz lendülni, az amúgy bagatell problémákon, és a végén el tudod mondani, hogy csináltál egy programot, de valóban érteni fogod, hogy miért is működik?
Segítség nélkül újra tudnád írni? Szóval a bagatell dolgok megkérdezése helyett, bizony elő kellene venned valami js-es online doksit, és legalább az alapokkal tisztába kerülnöd, ha már ez a választott nyelv, amin el akartál indulni.
Én kérek elnézést!
-
-
Jim-Y
veterán
válasz fordfairlane #5465 üzenetére
Ezt kifejtened kerlek? Bar tudom, hogy nem nekem szolt de erdekelne
-
Jim-Y
veterán
válasz fordfairlane #5467 üzenetére
A !x kifejezes nem azt jelenti, hogy x == false hanem
The production UnaryExpression : ! UnaryExpression is evaluated as follows:
Let expr be the result of evaluating UnaryExpression.
Let oldValue be ToBoolean(GetValue(expr)).
If oldValue is true, return false.
Return true.A ToBoolean a falsy ertekeket konvertalja boolean false-ra amit negalni fogunk true-ra. Tehat a !x az egy falsy check es ajanlott a hasznalata ha nincs szukseg explicit check-re.
-
Zedz
addikt
válasz fordfairlane #5465 üzenetére
Nem értem ezen mi a bad practice. Egyszerű falsy check. De ha én tudom rosszul akkor kérlek írd le miért bad practice.
-
inf3rno
nagyúr
Szvsz. nem bad practice. Nem minden esetben kell annyira szigorúan venni a típusellenőrzést. Főleg nem ha általában kivételeket dobunk hibánál, nem null-al és hasonlókkal térünk vissza. Ha mégis kell komolyabb típusellenőrzés, akkor ott a typescript, és megintcsak használható a !x vagy !!x, stb...
[ Szerkesztve ]
Buliban hasznos! =]
-
Jim-Y
veterán
válasz inf3rno #5471 üzenetére
Hat... Chrome console ->
function x_test(val) {
console.group();
console.log(!val);
console.log(val == false);
console.groupEnd();
}
[0, null, void 0, '', Number.NaN, [], {}, 2, "test"].forEach(x_test);
// output
VM586:3
VM586:4 true
VM586:5 true
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 true
VM586:5 true
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 false
VM586:5 true
VM586:3
VM586:4 false
VM586:5 false
VM586:3
VM586:4 false
VM586:5 false
VM586:3
VM586:4 false
VM586:5 falseNekem ez nem ugy tunik mint ami ugyanaz lenne
-
Jim-Y
veterán
válasz inf3rno #5472 üzenetére
Ezeknek nem az az ertelme, hogy tipusossa tegyunk egy dinamikusan tipusos nyelvet, ennek ondokumentacio meg self validation miatt van ertelme.
Pl ha van egy fuggveny ahol azt varod hogy tombbel hivjak meg, de biztosra akarsz menni, akkor
rossz esetben igy irod meg
function doStuff(inputArray) {
return inputArray.map(makeChange);
}Jo esetben pedig igy
/**
* @param {Array} inputArray
* @return {Array}
*/
function doStuff (inputArray) {
if (!inputArray || !utils.isArray(inputArray)) {
return [];
}
return inputArray.map(makeChange);
}Ondokumentalas, es annak a kodbeli leirasa, hogy te mint programozo milyen mukodesre irtad meg a fuggvenyt. Persze lehet ezt kevesbe expliciten is irni, pl:
function doStuff (inputArray) {
return (inputArray || []).map(makeChange);
}De ez utobbi megint csak a falsy value-k ellen ved, az ellen nem ha pl egy stringet adnak meg.
-
inf3rno
nagyúr
1.
Hja, meglepődtem. Leginkább a null-on... Ezt a validációs részét a js-nek már 10 éve is újra kellett volna írni szerintem. Az egész egy jó nagy katyvasz. Elég hasonló a PHP-hez ilyen téren.2.
Erre mondtam, hogyha annyira a típus validálással akarsz molyolni, akkor érdemesebb TypeScriptet használni.Én személy szerint így oldanám meg a dolgot sima js-el:
function doStuff (inputArray) {
if (!(inputArray instanceof Array))
throw new TypeError("Array required.");
return inputArray.map(makeChange);
}aszinkron esetben meg
function doStuff (done, inputArray) {
if (!(inputArray instanceof Array)) {
done(new TypeError("Array required."));
return;
}
done(null, inputArray.map(makeChange));
}Primitíveknél is ugyanúgy jó a typescript, vagy ha nem szeretnél compile-t, akkor valóban írhatsz olyat, hogy
if (utils.typeOf(value, String))
és hasonlókat.
Szvsz. nem muszáj minden esetben ennyire szigorúan típusellenőrizni. Attól függ, hogy mire fejleszted a kódot. Ha valami kisebb projekthez kell gyorsan összeszórni olyasmit, amit ránézésre átlátsz, akkor felesleges erre időt pazarolni.
Leginkább az a hátránya ennek a nem beépített típusellenőrzésnek, hogy TDD-vel a teszt kód nagy része erre megy el, ahelyett, hogy a tényleges funkciókat tesztelné az ember.
[ Szerkesztve ]
Buliban hasznos! =]
-
Jim-Y
veterán
válasz inf3rno #5471 üzenetére
Amugy hogy miert nem ugyanaz.
null == false vs. !null
null == false
=========1. http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
If Type(y) is Boolean, return the result of the comparison x == ToNumber(y).2. assert(typeof null === 'object')
3.
If Type(x) is Object and Type(y) is either String or Number,
return the result of the comparison ToPrimitive(x) == y.4. ToPrimitive(null) http://www.ecma-international.org/ecma-262/5.1/#sec-9.1
-> Null The result equals the input argument (no conversion).5. http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
10. Return false.!null
===1. !ToBoolean(null)
2. Boolean(null) -> false
3. !false -> true -
Jim-Y
veterán
válasz inf3rno #5475 üzenetére
Nem szabad kizarolag sem typeof -ot sem instanceof -ot hasznalni type checkingre. Van amire ez jo, van amire az. Univerzalis megoldas nincs, peldaul amire te hasznaltad az instanceof-ot arra nem valo es nem ajanlott mert hibakhoz vezethet.
instanceof and multiple context (e.g. frames or windows)
Different scope have different execution environments. This means that they have different built-ins (different global object, different constructors, etc.). This may result in unexpected results. For instance, [] instanceof window.frames[0].Array will return false, because Array.prototype !== window.frames[0].Array and arrays inherit from the former. This may not make sense at first but when you start dealing with multiple frames or windows in your script and pass objects from one context to another via functions, this will be a valid and strong issue. For instance, you can securely check if a given object is in fact an Array using Array.isArray(myObj)
Epp ezaz, hogy nem muszaj mindig tipusellenorizni, ezert is irtuk itt tobben is, hogy a !x es tarsai hasznalata javvallott!
De asszem mar boven korul lett ragva a topicUdv
inf3rno: typescript, dart, coffee, elm.. egyeni preferencia kerdese, szerintem ezek csak akkor hasznosak ha Java-n nevelkedett embernek kell JS kodot irnia. <tapasztalat>
[ Szerkesztve ]
-
inf3rno
nagyúr
"This may not make sense at first but when you start dealing with multiple frames or windows in your script and pass objects from one context to another via functions, this will be a valid and strong issue."
Nekem továbbra sincs értelme. Mármint persze elfogadom, hogy nem működik, mert a böngészőket így tákolták össze, de ez sajna jellemző a kliens oldali fejlesztésre, hogy nekünk kell alkalmazkodni mások hülyeségéhez. Eléggé conformist viszonyban vagyunk a böngészőgyártókkal, nem customer-supplier-ben, hogy DDD-s szavakat puffogtassak. Ez már a kezdetek kezdete óta így van sajnos. Nem véletlenül utáltam meg a kliens oldali fejlesztést, és mentem át inkább szerverre.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
"inf3rno: typescript, dart, coffee, elm.. egyeni preferencia kerdese, szerintem ezek csak akkor hasznosak ha Java-n nevelkedett embernek kell JS kodot irnia. <tapasztalat>"
Személy szerint én annak idején js-el kezdtem, mint script kiddie, és nekem tetszik a TypeScript. Java-t tanultam egy keveset, de inkább az erős oo alap, ami miatt bejön, nem pedig a Java tudás miatt. Te funkcionálisan programozol js-ben, legalábbis a kódjaid alapján, ahhoz gondolom megfelel az a validálási forma, amit használsz. Én inkább az oo fele hajlok, ahhoz meg más eszközök a jobbak, pl TDD, vagy újabban BDD az alap, meg hogy minden sor kód tesztelve van. Ennél a megközelítésnél nekem kifejezetten zavaró, ha típusellenőrzésre kell teszt kódot fecsérelni. Nagyjából ennyi a különbség.
[ Szerkesztve ]
Buliban hasznos! =]
-
Jim-Y
veterán
válasz inf3rno #5479 üzenetére
En Dartoztam egy darabig es nagyon tetszett, tenyleg, jo kis nyelv az, csak nem talalta meg a helyet a vilagban, de maga a nyelv az fasza Ennek ellenere most egy baromi nagy JS heavy projekten dolgozom es latom, hogy a tenyleges problemak csak egy baromi kis szeletet jelentik a tipusossagbol adodo gondok?. Nem neveznem gondoknak oket..mondjuk ugy hogy baromi ritkan van abbol gond, hogy a JS dinamikusan tipusos az esetek kb 1%-ban szamit. Es ha azt vesszuk alapul, hogy jo JS fejlesztoink vannak akkor egesz egyszeruen nem lenne elonye egy TypeScriptnek egy vanilla JS-hez kepest :/
-
Jim-Y
veterán
válasz inf3rno #5481 üzenetére
A kliens altal tamasztott kovetelmenyekkel altalaban. A business logic neha-neha annyira bonyolult es a specifikacio annyiszor valtozik menet kozben, hogy eleg nehez egy tenyleg jol mukodo feature-t osszehozni.
Illetve a oldalak kozti navigaciot sokszor eleg nehez hibamentesen osszehozni mert a kapcsolati halo eleg bonyolult es a statemanagement is problemassa valik(hat).
Ami mar inkabb programozas kozeli az a kulonbozo platformok tamogatasanak igenye es az ebbol fakado gondok. Kulonbozo WebView verziokat kell tamogatni es kulonbozo Oprendszereket es nem minden mukodik ugyanugy ezeken. Ezekkel nagy szivas van. Erdekes nyelvi szinten ebbol nincs problema. Szinte minden tamogatott environmenten mar olyan WebView van ami az Ecma 5.1-et teljes koruen tamogatja szv ebbol nincs gond.
Kb ugy ennyi..
[ Szerkesztve ]
-
inf3rno
nagyúr
A BDD-t és a DDD-t próbáltátok már, vagy ahhoz meg még túl kicsi a projekt?
Én most olvasom a Vaugh Vernon könyvet DDD-vel kapcsolatban. Elég jól leírja, hogy hogyan lehet szétszedni kezelhetőbb méretű részekre óriás alkalmazásokat. Szerintem kliens oldalra is használható az elv, ha már akkora lenne a kód.
A BDD-ehhez többé-kevésbé szorosan kapcsolódik. Nálam kb annyiról szól, hogy cucumber-ben megírod a use case-eket a domain model nyelvén, utána ezeket lefordítod tesztekre step definition-ökkel. Aztán teszteled vele az alkalmazást. Lehet csak a domain model-t is tesztelni, amiben a business logic van, de akár e2e teszteket is lehet írni, és a kliens oldalról megközelítve tesztelni az egész alkalmazást (ez jóval lassabb). Elég széles a tárház, hogy mit tudsz tesztelni, és nagyon rugalmas, mert a step definition-ök szabadon cserélhetőek úgy, hogy közben a use case-ek ugyanazok maradnak felettük. Ha változik a megrendelői igény a logikát tekintve, akkor változik a use case is, ellenkező esetben viszont csak a step definition-höz kell hozzányúlni, ha éppen gombra kell kattintani link helyett vagy ilyesmi egy űrlap küldéshez. Egyelőre ezzel is csak kísérletezek, de egyre inkább úgy tűnik, hogy be tudom venni hagyományos TDD helyett a napi rutinba.
A kliens oldalon örök szopás, hogy 1000 féle környezetet kell megtámogatni. Nem új dolog. Én futottam már bele mostanában natív js bug-ba is. Nagyon kellemetlen, mert órákon át lehet keresni a kódodban, hogy hol a hiba, miközben nem ott van, hanem a js motorban... Ha nem TDD-vel írtam volna a kódot, akkor elkapálhattam volna magam, mert debug-nál még nehezebb egy ilyet leszűkíteni pár sor kódra. TDD-nél azért képben vagy, hogy éppen mire írtad 1 perce a tesztet.
Async-hez te milyen lib-eket használsz?
[ Szerkesztve ]
Buliban hasznos! =]
-
Jim-Y
veterán
válasz inf3rno #5483 üzenetére
Sajnos amikor keszult a projekt akkor nem igazan gondoltak fejlesztesi modszertanokra azota pedig annyira kinotte magat a projekt hogy eleg nehez (khmmm ain't noone will pay for this) akar csak egy TDD-t is bevezetni. Az eddig megirt kodbazis 90% nem tesztelheto modulokban lett megirva nem olyan szempontok szem elott tartasaval, szv fck De azert probalkozik az ember mert igeny (most mar) lenne ra. Legalabbis fejlesztoi oldarol.
Async-hez sima jQuery -> AJAX/Deferred, legacy product es mint olyan jQuery-t hasznal, sajnos
A nativ hiba az mi volt?
[ Szerkesztve ]
-
inf3rno
nagyúr
Ha van szabadidőd, akkor a helyedben beleolvasnék a "ddd strategic design" részébe egy-két cikknek, könyvnek, ilyesmi, hátha találsz valamit, amit erre az esetre lehet alkalmazni. Rosszul megírt projekteken is lehet vele javítani valamennyit. Azért csodát ez sem tud tenni az eddigiek alapján.
A tesztek nélküli refaktorálás meg nem egy ajánlott dolog. Érdemes lenne legalább 1-2 e2e tesztet beletenni így utólag a main feature-ök tesztelésére, hogy nagyon fontos dolgok ne törjenek el, ha átírtok valamit. Ez azok alapján, amit elmondtál, bármikor megtörténhet, amikor hozzányúltok a kódhoz.
Sajna a legacy-val ez van általában. Egy idő után túl nagy erőfeszítés megjavítani, az ember legszívesebben újraírná az egészet, de azért meg nem fizet senki, mert hát a mostani a rendszer is "jól" működik. A refaktorálásért sem fizetnek, hacsak nem sikerül elmagyarázni nekik, hogy minél többször nyúltok hozzá a kódhoz ilyen formában, annál valószínűbb, hogy széthullik az egész.
Úgy emlékszem, hogy for-in-el próbálkoztam a bejárással, és az Object.defineProperty-nél az enumerable: false eltérően öröklődik az egyes böngészőkben. Valahol nem kerül be bejárásnál a listába az öröklött tulajdonság, valahol meg bekerül. Azt hiszem ugyanígy hibák voltak a setter, getter, congfigurable terén is, de ezt nem mondom biztosra. Küldtem mindegyik major böngészős cégnek bug report-ot, hogy jó lenne közös nevezőre jutni ezzel kapcsolatban, de egyik sem reagált, úgyhogy én inkább nem használom többet azt a függvényt meg a for-in-t bejárásra (kivéve config objecteknél, meg 1-2 helyen). Sugar syntax-hoz kellett volna csak, megoldottam másképp, úgyhogy nem lényeges.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Még régi msie-kben volt ez gond, amikor az enumerable nem volt implementálva és állandóan betette a konstruktort meg az Object.prototype-ban lévő dolgokat a for-in-be. Ma már van ES5 support, és hasOwnProperty nélkül is rendesen elmegy a for-in. Olyasmivel próbálkoztam, hogy enumerable: false-ra állítom a metódusokat, hogy néhány örökölt property-t be lehessen járni for-in-el. Ezeket kiszűrné a hasOwnProperty. Sajnos nem jött be a dolog a már említett böngészők közti eltérések miatt.
Igen, tisztában vagyok vele, hogy vannak erre callback-es megoldások, de én jobban szeretem a hagyományos ciklusokat, leginkább azért, mert sokszor elfelejtem kitenni a bind-ot a végére a callback-nek.
Buliban hasznos! =]
-
jetarko
csendes tag
Lehet olyat csinálni js-ben debug közben, hogy egy adott változó értékét megváltoztató sorokra ugrani debug közben, vagy kiíratni h melyik sor volt a tettes?
-
Karma
félisten
Szerintem nem szükségszerű, hogy a rossz érték beállítása után azonnal olvassa is valahol, így a stacktrace-ből nem sok látszik. Mondjuk az is egy jó kérdés, miért vannak pőrén változók, amit többen is állítgathatnak?
Egy darabig filóztam, hogy az Object.observe-vel nem lehetne-e megoldani a dolgot, de sajnos ott is csak a változás tényéről jön értesítés, a kiváltó ok nem látható.
[ Szerkesztve ]
“All nothings are not equal.”
-
jetarko
csendes tag
Az értéket az angular kódja változtatja meg egy kb 30soros loopban ami nagyon sokszor fut le. Így hát nincs kedvem végignyomogatni, de valszeg átírom majd a kódot és vmi if-et teszek bele.
A keresés közben ráakadtam erre a csodás kommentre:
// Insanity Warning: scope depth-first traversal
// yes, this code is a bit crazy, but it works and we have tests to prove it![ Szerkesztve ]
-
_ak_
addikt
Utólag is köszönöm mindenkinek a segítséget, bevallom eszembe sem jutott a SPA gondolata, pedig, magam is akartam barkácsolni gyakorlásképp, de ezek szerint annó nem sikerült az alapvető koncepcióját felfognom.
Pechemre most egyedül vagyok webes, úgy hogy erősen csillagközi invázió állapot van, de így legalább tudom, hogy az esetleges szabadidőmben érdemes foglalkozni a kérdéssel és nem akartam hülyeséget.
Let's begin, de gozaimasu!
-
cocka
veterán
Sziasztok!
Nem nagyon értek a javascripthez, de azt nagyjából sejtem milyen irányban kell keresgélnem.
Van ez a csodálatos honlap, hogy mno.hu. Ennek megvan az a jó szokása, amit rettenetesen utálok, hogy ha órákig meg van nyitva, akkor automatikusan lefrissül és ha pl. cikket olvastam és mondjuk elkattintottam máshová vagy vmi elterelte a figyelmem, mire visszatérek már le is frissült.
Van egy olyan sejtésem, hogy a millió js fájl egyikében rejtőzik az a settimeout függvény, amit keresek, csak kérdés, hogy melyikben. Az időtartamra sem tudok rájönni.
Régen ezt megoldották egy meta refresh taggel, aztán kész, ahhoz volt meta refresh blocker, de gondolom javascriptnél nem ilyen egyszerű a helyzet.
Ha valaki esetleg tud segíteni, megköszönöm.
-
dqdb
nagyúr
A kódot tartalmazó .js fájl blokkolása valószínűleg nem lesz jó, mert más funkciót is kinyírhatsz vele. Neked egy olyan user JS vagy extension kell (böngészőtől függ, melyik), ami document_start vagy DOMContentLoaded eseménykor (böngészőtől függ, melyik) lefut, és lecseréli a window.setTimeout vagy window.setInterval függvényeket (a weboldaltól függ, melyiket használja). De ezt is ésszel kell tenni, hogy tényleg csak azt a kérést blokkold, amelyik az újratöltésért felelős.
Most lusta vagyok összedobni egy pontosan ilyet, de íme egy Chrome/Opera extension, aminek hatására a böngésző letagadja, hogy tud WebM videót lejátszani, kiindulási pontnak tökéletes:
manifest.json
{
"content_scripts":
[
{
"matches": [ "http://*/*", "https://*/*" ],
"js": [ "content.js" ],
"run_at": "document_start"
}
],
"manifest_version": 2,
"name": "Test Script",
"version": "1.0.1"
}content.js
var patch = document.createElement("script");
patch.type = "text/javascript";
patch.innerText =
"HTMLVideoElement.prototype.canPlayType = function(type) { console.log('HTML5 video', type); return type.substr(0, 10) === 'video/webm' ? '' : this._canPlayType(type); };";
(document.head || document.documentElement).appendChild(patch);[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Sk8erPeter
nagyúr
Uhh, ezt én is de tudom utálni, régen ilyet a prog.hu is csinált, hogy automatikusan frissült a lap, de nem csak frissült, át is irányított, így hiába volt későbbi olvasásra félretéve pár cikk, ránéztem egy idő múlva, és már csak a címlapot láttam. Gratula annak, aki kitalálta... Írtam is nekik levelet ezzel kapcsolatban, hogy emiatt szoktam le a cikkjeik olvasásáról, hogy azóta is van-e ez a jelenség, fogalmam sincs, mert tényleg nem olvasom őket.
A kérdésre amúgy most érdemben nincs időm reagálni, de látom, kaptál már ötletet, csak hát JS-hez értés nélkül nehéz lesz ezekkel bármit is kezdeni... Amivel hozzákezdhetnél, az az, hogy megnyitod a webfejlesztő panelt, és az ottani keresővel minden, oldalról letöltött forrásban elkezded keresgélni (Blink-alapú böngészőkben (pl. Chrome, Opera) a Ctrl+Shift+F segítségével!) az említett "setInterval" és "setTimeout" szavakat.[ Szerkesztve ]
Sk8erPeter
-
Lacces
őstag
Hello!
Valaki próbált már NVM-el telepíteni nodejs-t?
Én ezzel próbátalm:
# Node Package Manager: NPM
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.25.4/install.sh | bash
source ~/.nvm/nvm.sh
nvm install node
nvm alias default node
de ez használhatatlan, valahányszor kilépek a szerverről, már el is tűnt a nodejs... nem jegyzi meg, újra kell installálni az nvm-en keresztül. (Mintha csak session-ben létezne)
Új hozzászólás Aktív témák
- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
- iPhone topik
- Sorozatok
- Diablo 3
- Villanyszerelés
- Kerékpárosok, bringások ide!
- Újabb Samsungok telepíthetik a Galaxy AI-t
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Mindent megtudtunk az új Nokia 3210-ről
- Milyen billentyűzetet vegyek?
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen