NurgaJS: `mall` vs `mallUrl`

Viimastel kuudel olen otsinud erinevaid viise, kuidas parandada hiiglasliku SPA, kus ma Domos töötan, tööaega. Oleme teinud tõsiseid edusamme, kuid miljonis reas koodiga ühes SPA-s pole mõned muudatused alati lihtsad. Üks meie meeskonna liikmetest tegi avastuse, et aidata lisada AngularJS-i projektidesse sujuvat laadimist ja me oleme sellesse palju investeerinud. Mõned erinevad meeskonnaliikmed (Jason ja Tim) aitavad meil mõõta aega, mis kulub meie rakenduse täielikuks initsialiseerimiseks. Oleme ka veebipaketti ehitise sujuvamaks muutmiseks ja mõnede mustrite muutmiseks kasutanud. Veebipaketi ja ocLazyloadi ühendamisel oleme leidnud AngularJS projektidele tõsise võidu.

Eelmisel nädalal võtsin ülesande muuta kõik komponentide / direktiivide mallideklaratsioonid ja muuta need mallistUrl malliks. Selle asemel, et kõiki malle nende eraldi .html-failidest käsitsi vastavatesse JS-failidesse teisaldada, otsustasime kasutada veebipaketi laadijat ja nõuda mallide sisestamist stringidena. Selle paremaks selgitamiseks ... lubage mul näidata teile, mida ma mõtlen. Järgnev on näidis AngularJS komponent:

Nagu näete, on esimeses näites komponent, mis kasutab malli laadimiseks malliUrl. Parimal juhul on see problemaatiline, IMO. See tähendab, et peate kas tootmiseks juurutama faili foo / bar / myComponent.html, et teie produktsioonirakendus saaks malli fragmendi laadida teise võrgutaotluse kaudu, VÕI see tähendab, et peate lisama ehituse samm, mis otsib kõik mallUrl eksemplarid ja viib need mallid nurgaJS templateCache'i. Mõlemal neist lahendustest on probleeme.

Esimesega seotud probleemid on ilmsed: kui kõik teie tootmisel olevad mallid nõudsid nende saamiseks eraldi võrgutaotlust, siis ühe vaate laadimiseks oleks vaja kõigi vaadete saamiseks N võrgutaotlust, kus N on komponentide arv / käskkirjad / ngSisaldab teie arvates.

Teise puhul on probleeme sellega, et ehitusetapid laadivad kõik käepärased mallid oma peamisse veebikotti, kuigi need on ülilihtsad. See tähendab, et isegi kui kavatsete mõne komponendi või terve osa komponentidest suvaliselt alla laadida, laaditakse nende mallid ikkagi teie peamisse paketti. Niisiis, te ei saa täielikult ära kasutada laisa laadimise eeliseid.

Arvestades neid sadu ja sadu malle, mis meil oma projektis on, ei olnud kumbki neist teostatav. Vajasime midagi muud. Vajasime midagi, mis võimaldaks meil oma malle tõhusalt laadida, ilma et oleks vaja eraldi võrgutaotlusi igaühe jaoks, võimaldades samas ka samu malle täielikult laisklaadida. Niisiis otsustasime kaaluda veebipakkide laaduri kasutamist, mis võimaldaks meil oma malle oma komponentideks nõuda HTML / nurgeliste mallide ridadena.

Eelised

Kasutades veebipaketi html-laadurit kõigi .html-failide laadimiseks avastasime, et suutsime oma malle tõhusalt laadida, võimaldades samal ajal ka sujuvalt allalaadimist täielikult ära kasutada. Kui kasutate malli: nõuda ('foo / bar / my.html') süntaks, asendab webpack teie nõudmisväljavõtte funktsiooniga, millele helistatakse ja tagastatakse koos malli stringi abil. Kuna mall on nüüd esitatud html-stringina, laaditakse komponent ka siis, kui laadite selle komponendi lazyload. See on täpselt see, mida me vajasime. Siiski avastasime mitmeid muid eeliseid, mille avastamine ajendas seda postitust.

  • Komponendi kiirem lähtestamine - kui kasutate mallina tekstisisest stringi, saab komponent lähtestada sünkroonselt. Kasutades templateUrl, taotleb AngularJS malli mallimuudade vahemälust. Kuna mallimudelil võib mall juba olla vahemällus või võib olla vaja selle saamiseks minna üle võrgu, on vahemälust malli taotlemine protsess, mis toimub asünkroonselt. Isegi kui mall on juba vahemälus, tagastab templateCache juba vahemällu salvestatud malli lubaduspõhise kõne kaudu. See tähendab, et komponent ei saa sama sündmuse ahelas lähtestada. Taotlus mallimälule paigutatakse alati järgmise sündmuse ahelale, isegi parima stsenaariumi korral. See tähendab, et komponent võib hakata vormindama, selle malli taotlema ja seejärel järgmise sündmuse ahelas lähtestama. Kuid kui kasutate tekstisisest stringi, on komponendil mall juba valmis, nii et selle algust saab alustada ja selle lõpetada samas sündmusetsüklis. See ei pruugi tunduda märkimisväärne, kuid sellel oli mitmeid ootamatuid tulemusi, mida me pidime kompenseerima. - Komponendid lähtestatakse kiiremini - mis kõlab fantastiliselt, õhkõrn? Noh, see on fantastiline. Kuid see tähendab, et mõnel teie komponendil, mille sisendväärtused on alati määratletud, kui nende lähtestamine võib puruneda, võivad need samad väärtused veel puududa. Sisendite määratlemata sisendväärtuste tõttu oli komponentide katkemine mitu. Pidime neid komponente muutma, et kasutada sisendväärtuste värskenduse tuvastamiseks $ watch või $ onChanges. - Ühiktestid töötavad erinevalt - Kuna testide kirjutamine muutub sünkroontesti või asünkroonse testi korral, võib nende komponentide test kindlasti muutuda. Näiteks süstige Mochas, kui teie test on asünkroonne, testi sisestatud meetod ja helistage sellele siis, kui test on tehtud. Leidsime, et testid toimusid nüüd sünkroonselt, mis tähendas, et tehtud süstimisvajadus polnud enam vajalik. Veelgi enam, ja seda on piinlik tunnistada, kuid meil olid testid, mis kirjutati sünkroonselt, kuna mallid olid asünkroonsed, neid teste pole KUNAGI kunagi edukalt läbi viidud. Niisiis, kui ma vormistasin muudatused mallide sisestamiseks, hakkasid need testid edukalt käima ja läbimise asemel olid need RIKKUMISED !!!! Alguses arvasin, et olen kõik need testid rikkunud. Alles pärast viietunnist ringi nokitsemist sain aru, et need testid ei lähe kunagi läbi. Nii et nüüd, kui kasutame tekstisiseseid malle, on katsete ulatus tegelikult suurenenud.
  • html-loader kasutab html-minifikaatorit - see väike fakt vähendas meie mallide mahtu kogu rakenduses 19% võrra. See on nii silmapaistev ja on tõesti asi, mida oleksime pidanud juba pikka aega tegema. Samuti parsib mallid ja aitas meil leida mõnikümmend malli, milles html oli kehtetu. Asjad nagu: klass "blah", kus = puudus. Või atribuut = {{midagi}}, millel puuduvad tsitaadid selle kõige ümber. Kui need parandasin, töötas ehitis uuesti.
  • ng-hõlmatud olid endiselt katki - kuigi komponentide mallid nüüd töötasid, olid ng-kaasamised nüüd katki. Meil oli vaja nende jaoks midagi välja mõelda. Ehitasime siis väikese kohandatud laaduri, mis viib malli mallimuutisse. Meie sisemised tavad ütlevad, et me ei tohi kasutada ng-lisada, kuid meil on endiselt palju 3-aastaseid ja neid sisaldavaid koode. Niisiis, selle ümberlükkamise asemel kasutasin seda uut laadijat ja läksin rakenduse igasse sektsiooni, millel on ng-include, ja laadisin selle jaotise malli, nagu ma allpool näitasin. See tähendab, et ka uues protsessis hoolitsetakse ka ng-kaadrite eest.

Kasutatud JSCodeShift

Soovitan täielikult kasutada AngularJS-i rakenduste jaoks veebipaketti ja kasutada mallide tekstisiseseks toomiseks html-laadurit, mis tähendab, et peate mallidUrl-eksemplarid muutma mallide esinemisjuhtudeks. Kuna need kõik näevad välja väga erinevad, otsustasin, et see on Facebooki projekti JSCodeShift, mis võimaldab teil AST-d indekseerida ja programmiliselt asendada kõik teie esinemisjuhud, väga hea kasutusjuhtum. Võite mõelda selle kohta kui steroidide otsimine ja asendamine, süstitud koos rohkemate steroididega. Skripti kirjutamine, mis leidis kõik mallUrl kõik kasutusviisid ja neid uuendas: 'mõned / url / to.html malliga: nõuda (), oli tõesti lihtne. Suutsin 90% kasutusaladest programmiliselt muuta (umbes 700 faili) ja viimased 70 pidin käsitsi lõpetama. Oleksin võinud koodi kirjutada, et need ülejäänud 70 lõpule viia, kuid arvasin, et saan neid käsitsi lihtsamini teha, kui proovida neid igaüks eraldi kodeerida. Kiire märkus: AST Explorer on JSCodeShifti kasutamisel absoluutne kohustus. Ilma selleta poleks ma suutnud edusamme teha.

Järeldus

Hankige oma AngularJS-i rakendused veebipaketi ehitamiseks ja pange aega nende üleandmiseks HTML-laaduri kasutamisele mallide laadimiseks. Kasutage malliUrl asemel malli ja kui te seda veel teinud pole, siis lõpetage ng-include'i kasutamine. Ja siis, lazyload, lazyload, lazyload! Mõnikord eristavad inimesed hilinenud laadimist ja laiska laadimist. Ma pean silmas nii viivitatud kui ka laiska laadimist, kui ütlen “lazyload”. See on teie parim muudatus, kui lühendate aega esimese tähendusrikka maalini ja aega, mis kulub rakenduse loomiseks, millega kasutaja saab suhelda. Edu. Pea tagasi!