Vue.js rakenduse täiustamine. Mõned praktilised näpunäited
Dominik Grzedzielski
Vanem Software Engineer
Vue on kiiresti kasvav progressiivne raamistik kasutajaliideste loomiseks. Sellest sai JavaScript raamistik, millel on GitHubis kõige rohkem tärne ja mis on samas portaalis 2016. ja 2017. aasta kõige rohkem tärne saanud projekt.
Rakenduste loomine Vue on iseenesest väga lihtne, kuid kui soovite luua kvaliteetseid rakendusi, siis on teil veidi rohkem väljakutseid.
Olles osa The Codestmeeskond ja tõeline kaitsja Vue tehnoloogia, tahan ma jagada mõningaid näpunäited (ei ole kopeeritud ametlikest Vue dokumentidest), mis parandab vaevata kood kvaliteeti ja Vue rakenduste jõudlus.
Seal on neli reegli kategooriat. Me hoolime neist kolmest:
Oluline reeglid, mis takistavad meid vigade eest,
Soovitatav ja tungivalt soovitatav reeglid parimate tavade järgimiseks - et parandada kvaliteeti ja koodi loetavus.
Te võite mõelda... "Mida?! Kas ma pean iga reeglit meeles pidama?" Muidugi ei pea. Sa võid kasutada ESLint'i, et neid reegleid sinu eest ära õppida. Teil tuleb lihtsalt kõik ESLint'i konfiguratsioonifailis õigesti seadistada. Soovitan kasutada soovitatav eelseadistatud kuna saate täiesti tasuta reeglistiku, mis aitab teil luua rakendusi heade tavadega. Kuidas seda sisse seada?
Vaikimisi peaksite leidma laiendab võtit ESLint config'is ja asendage "plugin:vue/essential" koos "plugin:vue/recommended"See on kõik.
Loomulikult tuleb meeles pidada mõningaid reegleid, sest ESLint ei saa kõigega ise hakkama. Näiteks:
järjekindel nimetamine,
sündmuste nimetamine kebab-kategoorias,
eesliide $_namespace_ privaatsed omadused pluginates, mixinites jne..,
ühe faili komponendi ülemise taseme elementide järjestus.
Ärge kasutage mitut v-if
Mõnikord võib olla vaja tingimuslikult rohkem kui 1 elementi esitada, kuid inimesed kirjutavad sageli midagi sellist:
sisu
sisu
sisu
See on ebavajalik, sest me saame seda elegantsemalt kirjutada:
Aga mis siis, kui me tahame seda teha juurelemendina? Veebilehel Vue, ei saa me kasutada sel eesmärgil. Mõnel juhul võib piisata ka div-i pakkimisest.
See on ok, kuid nii palju kui me ka ei taha, mõnikord ei saa me näiteks html semantika tõttu elemente div-i sisse mähkida (nt. peab olema otsene laps
või ). Nii et kui me peame kirjutama:
(( item.name ))
...ja me näeme sellist viga :
Me saame sellega tegeleda kasutades JSX-i ja funktsionaalset komponenti, samuti peaksime edastama boolean ja see asendab v-if.
Ära kirjuta api-kõne käitlejaid komponentidesse
Tegelikult on see vaid üks näide sellest, mida te ei tohiks komponentides teha. Tehke lihtsalt seda, mis on komponentide loogikas lokaalselt vajalik. Iga meetod, mis võiks olla väline, tuleks eraldada ja kutsuda ainult komponentides, nt äriloogika.
Kasutage suure hulga rekvisiitide asemel teenindusajad
Mõnikord on rekvisiitide kasutamine lihtsalt piisav, kuid on ka juhtumeid, mil need ei ole tõhusad. See võib juhtuda olukordades, kus me peaksime lisama liiga palju rekvisiite, et komponent töötaks nii, nagu me tahame. Kõige lihtsam näide võiks olla nupukomponent. Kahtlemata on see komponent, mida võiks kasutada kõikjal rakenduses. Seega, vaatleme sellist nupukomponenti.
(( tekst ))
Praeguses etapis on tegemist lihtsa komponendiga, mis võtab vastu ainult teksti prop. Ok, kuid sellest ei pruugi piisata, sest me vajame nupule ikoone. Sellisel juhul peame lisama veel 2 rekvisiiti (2, sest me tahame, et oleks võimalus lisada enne või pärast teksti). Nii et komponent näeb välja selline:
(( tekst ))
See ei ole halb, meil on ainult 3 rekvisiiti, kuid...
Mis siis, kui vajame laadimisindikaatorit? Noh, siis peaksime lisama veel ühe tugipunkti. Ja seda iga uue funktsiooni puhul! Kas komponentide arvu kasvuga sammu pidamine kõlab nüüd väljakutse? Jah, kindlasti tundub!
Kasutame selle asemel teenindusajad.
Lihtsam, eks ole? Ok, aga kuidas me saame ikooni lisamise funktsiooni? See on tõesti lihtne! Lihtsalt kasutage komponenti nii:
Tagasi
Järgmine
Lihtne viis tulemuslikkuse parandamiseks
Jagan teiega mõned näpunäited, mida on tõesti lihtne rakendada, nii et saate kohe kasu.
Laised laadimisteed
Mõnikord on meil marsruute, mis on kättesaadavad ainult administraatoritele või kasutajatele, kellel on eriline juurdepääs, neid võidakse külastada vähem kui teisi. Need on ideaalsed juhtumid laiskade laadimisviiside kasutamiseks.
Lihtsalt kasutage noole funktsiooni oma komponendi omaduses, et tagastada importfunktsioon:
Tänu selle komponendi laiskale laadimisele laetakse see alla ainult siis, kui seda nõutakse. Näiteks, kui meil on komponent v-if, siis seda taotletakse ainult siis, kui komponent tuleb renderdada. Seega, kui v-if väärtus ei ole true, siis komponenti ei laadita. Seetõttu saab laisket importimist kasutada ka selleks, et kasutada JavaScript failid.
Boonus: Kui kasutad Vue CLI 3+, siis on iga laiskalt laetud ressurss vaikimisi eelkoostatud!
Kasutage läbipaistvaid ümbriseid atribuutide rekvisiitide asemel
Mõelge sellisele komponendile:
Ilma igasuguste probleemideta saame seda kasutada niimoodi:
või
See toimib, sest Vue võimaldab teil edastada komponendile html-atribuute, isegi kui te ei ole neid rekvisiitidena deklareerinud. html-atribuute rakendatakse komponendi juurelemendile (antud juhul sisend).
Probleem ilmneb siis, kui me tahame laiendada oma sisendkomponenti, sest see võiks välja näha nii:
ei tööta nii, nagu me tahame, sest tüüp ja paigutuskirje rakendatakse div (juurelemendile) ja see ei ole mõttekas. Seega peame sellega tegelema, sest me tahame lisada oma atribuudid sisendelemendile. Teie esimene mõte võib olla "lisame vajalikud rekvisiidid!" ja muidugi see toimib, aga... mis siis, kui me tahame kasutada tüüp, Automaatne täitmine, platsihoidja, autofookus, puudega, inputmode, jne, siis peame määratlema rekvisiidid iga html-atribuudi jaoks. Mulle isiklikult ei meeldi see pikk meetod, seega otsime midagi paremat!
Me saame kogu probleemiga tegeleda vaid kaks rida.
Me võime kasutada v-bind="$attrs" ja anda atribuute otse ilma tohutuid rekvisiite deklareerimata. Samuti tuleb meeles pidada võimaluse lisamist inheritAttrs: false et keelata atribuutide edastamine juurelemendile. Läheme veidi edasi: mis siis, kui meil on vaja lisada sellele sisendile sündmuste kuulajad? Jällegi võiks seda käsitleda rekvisiitide või kohandatud sündmuste abil, kuid on olemas parem lahendus.
On uus arvutatud omadus, mis tagastab komponendi kuulajate jaoks ja lisab sisendkuulaja. Me kasutame seda arvutatud sisendit, kirjutades lihtsalt v-on="listeners".
Kasutage valvurit koos vahetu valikuga, selle asemel, et luua konks ja valvur koos
Sageli hangime mõned andmed loodud (või paigaldatud) konksu korral, kuid siis peame neid andmeid hangima iga omaduse muutmise korral, nt lehekülje jooksva lehekülje puhul. Mõned kipuvad seda nii kirjutama:
Muidugi, see toimib, aga... See ei ole parim lähenemine, isegi mitte hea. Niisiis, vaatame, kuidas me saame refaktoorida seda, Näide mitte nii halb lähenemine:
Ülaltoodud versioon on parem, sest teist meetodit ei ole vaja, me nimetasime ainult meetodi, mida tuleks kutsuda watchedProperty muutmiseks.
Veelgi parem lähenemine:
Saime lahti loodud konksust. Lisades valiku 'immediate', teeme selle komponendi üleskutse meetodile fetchData kohe pärast vaatluse algust (see on natuke enne loodud konksu ja pärast beforeCreated), nii et seda saab kasutada loodud konksu asemel.
Vue.js nõuannete kokkuvõte
Need näpunäited ei tee teie taotlust täiuslikuks, kuid nende kasutamine teeb kiiresti parandada oma koodi kvaliteeti. Samuti loodan, et leiate ülaltoodud näidetest midagi huvitavat.
Pange tähele, et mõned neist on artikli tarbeks lihtsustatud.