Vue is een snel groeiend progressief framework voor het bouwen van gebruikersinterfaces. Het werd het JavaScript framework met de meeste sterren op GitHub en het meest gewaardeerde project van 2016 en 2017 op hetzelfde portaal.
Toepassingen maken in Vue is op zich heel eenvoudig, maar als je applicaties van goede kwaliteit wilt bouwen, heb je wat meer uitdaging nodig.
Deel uitmaken van The Codestteam en echte voorstander van Vue technologieIk wil wat delen tips (niet gekopieerd uit de officiële Vue-documenten) die moeiteloos het volgende zal verbeteren code kwaliteit en de prestaties van Vue-toepassingen.
Er zijn vier regelcategorieën. We geven echt om drie ervan:
Essentieel regels die voorkomen dat we fouten maken,
Aanbevolen en sterk aanbevolen regels voor het bijhouden van best practices - om kwaliteit verbeteren en leesbaarheid van code.
Je denkt misschien... "Wat?! Moet ik elke regel onthouden?" Natuurlijk niet. Je kunt ESLint gebruiken om die regels voor je te onthouden. Je moet alleen alles goed instellen in het ESLint configuratiebestand. Ik stel voor om de aanbevolen voorinstelling want je krijgt een volledig gratis set regels die je helpen om apps te bouwen met goede praktijken. Hoe stel je het in?
Standaard zou je het volgende moeten vinden breidt uit sleutel in ESLint config en vervang "plugin:vue/essentieel" met "plugin:vue/aanbevolen".dat is alles.
Natuurlijk zijn er een paar regels die je moet onthouden, omdat ESLint niet alles zelf kan. Bijvoorbeeld:
consistente naamgeving,
gebeurtenissen benoemen in kebab-valuta,
voorvoegsel $_naamruimte_ privé-eigenschappen in plugins, mixins, enzovoort,
volgorde van elementen op het hoogste niveau van een bestandsonderdeel.
Gebruik niet meerdere v-if
Het kan soms nodig zijn om conditioneel meer dan 1 element weer te geven, maar mensen schrijven vaak zoiets:
inhoud
inhoud
inhoud
Het is niet nodig omdat we het eleganter kunnen schrijven:
Maar wat als we het als root-element willen doen? In Vuekunnen we niet <template> voor dit doel. In sommige gevallen kan een verpakking in div voldoende zijn.
Dat is prima, maar hoe graag we het ook zouden willen, soms kunnen we elementen niet in div wikkelen, bijvoorbeeld vanwege html-semantiek (bijv. moet een direct kind zijn van
of ). Dus als we moeten schrijven:
(( item.naam ))
...en dan zien we zo'n foutmelding:
We kunnen het aanpakken door met behulp van JSX en een functioneel componentOok moeten we een boolean doorgeven en het zal de v-if vervangen.
</>
Schrijf geen api call handlers in componenten
Eigenlijk is dit slechts een van de voorbeelden van wat je niet moet doen in componenten. Doe gewoon wat lokaal nodig is in componentenlogica. Elke methode die extern zou kunnen zijn, moet worden gescheiden en alleen worden aangeroepen in componenten, bijvoorbeeld bedrijfslogica.
Gebruik gleuven in plaats van grote hoeveelheden rekwisieten
Soms is het gebruik van props net genoeg, maar er zijn ook gevallen waarin ze niet efficiënt zijn. Dit kan gebeuren in situaties waar we te veel props moeten toevoegen om het component te laten werken zoals we willen. Het eenvoudigste voorbeeld is een knopcomponent. Het is ongetwijfeld een component dat overal in een toepassing kan worden gebruikt. Laten we dus eens kijken naar een knopcomponent zoals deze.
(( tekst ))
In dit stadium is het een eenvoudig component dat alleen tekstvoorstellen accepteert. Oké, maar het is misschien niet genoeg omdat we pictogrammen nodig hebben in de knop. In dat geval moeten we nog eens 2 props toevoegen (2, omdat we de optie willen hebben om voor of na tekst toe te voegen). Het component ziet er dan zo uit:
(( tekst ))
Het is niet slecht, we hebben maar 3 rekwisieten, maar...
Wat als we een laadindicator nodig hebben? Dan moeten we nog een prop toevoegen. En dat voor elke nieuwe functie! Klinkt het nu uitdagend om de groei van het aantal onderdelen bij te houden? Ja, dat doet het zeker!
Laten we in plaats daarvan slots gebruiken.
Eenvoudiger, toch? Oké, maar hoe krijgen we de functie pictogram toevoegen? Dat is heel eenvoudig! Gebruik de component gewoon op deze manier:
Terug
Volgende
Eenvoudige manier om prestaties te verbeteren
Ik zal een aantal tips met je delen die heel gemakkelijk te implementeren zijn, zodat je er direct van kunt profiteren.
Lazy load routes
Soms hebben we routes die alleen beschikbaar zijn voor admins, of gebruikers met bepaalde toegang, ze kunnen ook minder bezocht worden dan andere. Dit zijn perfecte gevallen om de lazy load route te gebruiken.
Gebruik gewoon de pijlfunctie in je componenteigenschap om de importeerfunctie te retourneren:
Dankzij de lazy load van dat component, wordt het alleen gedownload als het wordt opgevraagd. Als we bijvoorbeeld een component hebben met v-if, zal die alleen worden opgevraagd als de component moet renderen. Dus tenzij de v-if waarde waar is, wordt de component niet geladen. Daarom kan lui importeren ook worden gebruikt voor JavaScript bestanden.
Bonus: Wanneer je Vue CLI 3+ gebruikt, wordt elke lazy loaded bron standaard geprefetched!
Gebruik transparante wrappers in plaats van attribuutprops
Overweeg een component als deze:
Zonder problemen kunnen we het als volgt gebruiken:
of
Het werkt, omdat Vue laat je toe html attributen door te geven aan de component, zelfs als je ze niet als props hebt gedeclareerd. De html-attributen worden toegepast op het basiselement van de component (in dit geval input).
Het probleem verschijnt wanneer we onze invoercomponent willen uitbreiden, omdat deze er als volgt uit zou kunnen zien:
zal niet werken zoals we willen, omdat het type en de placeholder zullen worden toegepast op div (basiselement) en dat heeft geen zin. We moeten er dus iets aan doen, want we willen onze attributen toevoegen aan het invoerelement. Je eerste gedachte is misschien "laten we de attributen toevoegen die we nodig hebben!" en natuurlijk werkt dat, maar... wat als we het volgende willen gebruiken type, autoaanvullen, placeholder, autofocus, uitgeschakeld, ingangsmodusenz., dan moeten we de props definiëren voor elk html attribuut. Persoonlijk houd ik niet van deze lange methode, dus laten we op zoek gaan naar iets beters!
We kunnen het hele probleem behandelen in slechts twee regels.
We kunnen v-bind="$attrs" en attributen direct doorgeven aan <input> zonder enorme hoeveelheden rekwisieten te declareren. Denk ook aan het toevoegen van de optie inheritAttrs: false om het doorgeven van de attributen aan het rootelement uit te schakelen. Laten we nog iets verder gaan: wat als we event listeners moeten toevoegen aan deze invoer? Nogmaals, dit zou kunnen worden afgehandeld door props of aangepaste gebeurtenissen, maar er is een betere oplossing.
Er is een nieuwe berekende eigenschap die de component voor luisteraars retourneert en de invoerluisteraar toevoegt. We gebruiken die berekende invoer door simpelweg het volgende te schrijven v-on="luisteraars.
Gebruik watcher met de optie onmiddellijk in plaats van de aangemaakte haak en watcher samen
We halen vaak gegevens op bij een aangemaakte (of gemounte) hook, maar dan moeten we die gegevens ophalen bij elke verandering van een eigenschap, bijvoorbeeld de huidige pagina van de paginering. Sommigen hebben de neiging om het als volgt op te schrijven:
Natuurlijk werkt het, maar... Het is niet de beste aanpak, zelfs geen goede. Dus laten we eens kijken hoe we dit kunnen herformuleren, Een voorbeeld van een niet zo slechte benadering:
De bovenstaande versie is beter omdat een andere methode niet nodig is, we hebben alleen een methode benoemd die moet worden aangeroepen om de watchedProperty te wijzigen.
We hebben de created hook verwijderd. Door de optie 'immediate' toe te voegen, laten we die component de fetchData methode direct na de start van de observatie aanroepen (het is iets voor de created hook en na beforeCreated), zodat het gebruikt kan worden in plaats van de created hook.
Vue.js tips samenvatting
Deze tips zullen je sollicitatie niet perfect maken, maar als je ze gebruikt, zal dat wel snel gebeuren de kwaliteit van je code verbeteren. Ik hoop dat je iets interessants zult vinden in de bovenstaande voorbeelden.
Merk op dat sommige vereenvoudigd zijn voor dit artikel.