Példák a javascriptre, amely segít elkerülni a hibákat!
1. Ezt helyesen használja zárószerkezeteknél
Hiba következik be:
Miért történik ez? Mindez összefüggésben áll. Amikor hívod a setTimeout () függvényt, akkor valójában window.setTimeout (). Ennek eredményeképpen a setTimeout () által átadott névtelen funkció az ablakobjektum kontextusában van meghatározva, amely nem rendelkezik clearBoard () metódussal.
Egy hagyományos megoldás, amely kompatibilis a régebbi böngészőkkel, egyszerűen egy hivatkozást tárol egy olyan változón, amely zárható:
Az új böngészők esetében használhatja a bind () metódust, amely lehetővé teszi, hogy egy függvényt társítsanak a végrehajtási környezethez:
3. Memória szivárgás
A memória szivárgások szinte elkerülhetetlenek, ha a munka során ön nem tudatosan elkerüli őket. Sok oka van a szivárgások előfordulásának, de a leggyakoribbakra koncentrálunk.
Nem létező objektumokhoz való linkek
Elemezzük ezt a kódot:
Ha végrehajtja a végrehajtás kódját, akkor nagyméretű memóriaszivárgást észlelhet kb. Megabájt per másodperc sebességgel. Úgy tűnik, hogy a longStr alatt allokált memóriát elveszítjük minden alkalommal, amikor a cserehelyet hívjuk. Mi az oka?
A lezárás végrehajtásának tipikus módja az, hogy létrehozzunk egy linket az egyes funkció objektumok és a szótárobjektumok között, ami ennek a funkciónak a lexikális köre. Ha mindkét funkció (nem használt és someMethod), bizonyos vnutrireplaceThing ténylegesen felhasznált priorThing, fontos megérteni, hogy ők egy és ugyanaz a tárgy, akkor is, ha priorThing újraírt újra és újra, mivel mindkét funkció ugyanazt a lexikális körét. És amint a változót bármelyik lezárásnál használják, akkor az az összes hatályos zárókör által használt lexikai körbe tartozik. És ez a kis árnyalat egy erős memória szivárgáshoz vezet.
Ciklikus linkek
Tekintsük a kód példát:
- amelyekre hivatkozások vannak a híváscsomagban (az összes helyi változó és függvényparaméter, amelyek jelenleg hívásra kerülnek, valamint a bezárás körébe tartozó összes változó);
- minden globális változó.
Az objektumokat csak a memóriában tárolják, mindaddig, amíg elérhetők a gyökérről referenciaként vagy egy linklánc szerint.
A böngészőkben egy szemétgyűjtő van beépítve, amely eltávolítja a memóriát a nem elérhető objektumokról. Ez azt jelenti, hogy az objektum csak akkor törlődik a memóriából, ha a szemétgyűjtő úgy dönt, hogy nem érhető el. Sajnálatos módon a fel nem használt nagy objektumok, amelyek "megvalósíthatónak" tekinthetők, könnyen felhalmozódhatnak.
4. Az egyenlőség félreértése
Amint azt a fenti két példa mutatja, az automatikus típusú konverzió időnként zavarhat. Általában a legjobb a === és! == helyett == és! =, A típusátalakítás mellékhatásainak elkerülése érdekében.
Egyébként a NaN és valami (még a NaN! -val is) összehasonlítása mindig hamis eredményt ad. Így nem használhat egyenlőség-üzemeltetőket (==, ===. =. ==) a NaN megfelelőségének megállapításához. Ehelyett a beépített globális isNaN () függvényt kell használni:
5. Helyesen használja a DOM-ot
Ha több elemet szeretne hozzáadni, akkor alternatívaként a dokumentum töredékeit is használhatja:
6. A funkciók meghatározásának helyes használata a hurkokon belül
Tekintsük a kód példát:
A 10 elem közül bármelyikre kattintva megjelenik az "Ez az elem # 10" üzenet. Ennek az az oka, hogy az onklick bármelyik elemének idõpontjában hívják, a hurok megszakad és az i értéke 10 lesz.
Példa a helyes kódra:
A makeHandler azonnal megkezdi a hurok mindegyik iterációját, megkapja az i + 1 aktuális értékét, és tárolja a num változóban. A külső függvény egy belső függvényt (amely a num változót is használja) és egy onclick kezelőként állítja be. Ez lehetővé teszi annak biztosítását, hogy minden egyes onclick megkapja és felhasználja az i helyes értékét.
7. A megfelelő örökség a prototípusokon keresztül
Meglepő módon sok fejlesztő nem rendelkezik egyértelmű megértéssel az öröklés mechanizmusával a prototípusok révén. Tekintsük a kód példát:
De ha így írtuk:
De nem jobb, ha visszaad egy értéket az alapértelmezettnek? Ez könnyen elvégezhető az örökségnek a prototípusok segítségével történő alkalmazásával:
A BaseObject minden egyes példány örököli annak prototípusának nevét, amelyben az alapértelmezett. Így, ha a konstruktort név nélkül hívják, az alapértelmezett tulajdonságnév az alapértelmezett. Hasonlóképpen, ha a tulajdonság neve törlődik a példány BaseObject keresés végrehajtása a prototípus lánc és ingatlan namebudet nyert prototípusobjektumai, ahol ez még mindig egyenlő az alapértelmezett:
8. Hozzon létre helyes hivatkozásokat a példánymódokra
Adjon meg egy egyszerű konstruktort, és használja objektum létrehozásához:
A kényelem érdekében hozzon létre egy linket a whoAmI módszerhez:
Mutassuk be az új változó értékét, akiAmI:
A konzol a következőket jeleníti meg:
És most figyeljen az obj.whoAmI () és callsAmI () hívások közötti különbségre:
Mi ment rosszul? Amikor hozzárendeltük a var, akiAmI = obj.whoAmI;, az új változót a globális névtérben definiáltuk. Ennek eredményeképpen ez egyenlő volt az ablak, nem obj, a MyObject példával. Tehát, ha valóban szükségünk van hivatkozásra egy meglévő objektummódszerre, ezt az objektum névtérén kell elvégeznünk. Például:
9. A string használata az első argumentum a setTimeout vagy setInterval
Ez önmagában nem hiba. És ez nem csak a teljesítményről szól. Az a tény, hogy amikor egy string változót átad az első argumentumnak a setTimeout vagy a setInterval mezőben, akkor átkerül a Function konstruktorba, hogy új függvényt alakítson át. Ez a folyamat lassú és nem hatékony. Alternatívaként a függvényt első argumentumként kell használni:
10. A "szigorú üzemmód"
Ez egy olyan mód, amelyben számos végrehajtható kód korlátozása kerül bevezetésre, ami növeli a biztonságot és megakadályozhatja bizonyos hibák előfordulását. Természetesen a "szigorú rezsim" használatának megtagadása önmagában nem hiba. Egyszerűen ebben az esetben számos előnyt foszt meg magától: