typeOf(valami) === "undefined"

Gondolom a valami helyére a változót kell írni....?

[ Szerkesztve ]

Samsung Galaxy S21 ---- Hirdetéseim: http://bit.ly/2tWSizn

Ja persze, mert két egyenlőségjellel szerepelt csak. Én is elsőre ezt az if(!valami)-t akartam elsőre írni, csak rémlik, hogy ennél mintha egy fokkal biztonságosabb lenne a typeOf-os ellenőrzés. De lehet, hogy csak túlbonyolítom.

Én kérek elnézést!

Igen, oda a változó neve megy. De szerintem is jobb az if-es megoldás, amit Jim-Y kolléga ajánlott.

Tasker esetén főleg.

Samsung Galaxy S21 ---- Hirdetéseim: http://bit.ly/2tWSizn

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 ]

Ez a lodash pontosan mit tud?

Pont ugyanaz mint az underscore. Utility library.

Lehet hogy hülyének néztek, de van ilyen undefied paraméter if-nél?

Valtzozo = .................weather; if (Valtozo === undefied)

Vagy ez így csak akkor müxik, ha a szöveg = undefied?

Samsung Galaxy S21 ---- Hirdetéseim: http://bit.ly/2tWSizn

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.

"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...

A NaN-t kihagytad de amugy OK.

Ismerem a falsykat, de most csak az undefined volt a kérdés.

[ Szerkesztve ]

Köszi.

Azt hiszem bele kénne ássam magam jobban a témába.

Samsung Galaxy S21 ---- Hirdetéseim: http://bit.ly/2tWSizn

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!

Ezt kifejtened kerlek? Bar tudom, hogy nem nekem szolt de erdekelne

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.

Nem értem ezen mi a bad practice. Egyszerű falsy check. De ha én tudom rosszul akkor kérlek írd le miért bad practice.

Nekem még mindig azt jelenti, hogy
x == false
Boolean(x) === false
!!x === false
!x === true
és így tovább, de hallgatom az ellenpéldákat, hogy ezek mikor nem adnak azonos eredményt, mint a !x.

Buliban hasznos! =]

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! =]

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 false

Nekem ez nem ugy tunik mint ami ugyanaz lenne

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.

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! =]

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

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 topic

Udv

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: 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! =]

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 :/

Elhiszem. :-)

Mivel vannak nagyobb gondok, ha nem céges titok?

Buliban hasznos! =]

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 ]

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! =]

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 ]

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! =]

Protip: for ..in + hasOwnProperty helyett Object iteration-re:

Object.keys(obj).forEach(function(key) {
// obj[key]
})

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! =]

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?

Beteszel egy breakpointot a valtozora amiben mar a rossz ertek szerepel, majd a stack trace-ben elkezdesz visszafele kattintgatni.

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.”

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 ]

Chrome-ban vannak felteteles breakpointok azok nem tudnak segiteni?

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.

Ez jó lenne, csak éppen ez minden oldalnál figyelmeztet, amit viszont nem akarok. Viszont ha tudom melyik jsben van a refresh marhaság, akkor azt adblockkal esetleg le tudom tiltani.

Ezt az oldal csinálja, nem a böngésződ alap feature-e?
Tipikusan olyat szeretnél, amire egyébként mi sem tudunk neked válaszolni. F12-vel kezdj el keresgélni az oldal forrásában, aztán vagy megtalálod amit keresel, vagy nem.

Én kérek elnézést!

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

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