Vue Framework the 3rd – Så, hva er nytt?

**automatisk oversatt tekst**

Etter mange kunngjøringer og beta-utgivelser, ønsker vi endelig velkommen til markedet Vue 3, et av de mest populære frontend-rammeverket.

På den ene siden en ny måte å lage komponenter på – man kan si at det til og med er en revolusjon. På den andre, muligheten til å holde seg i komfortsonen - takket være bakoverkompatibilitet kan du fortsatt bruke den gamle API-en til å lage apper. For godt til å være sant? La oss se og diskutere hva de viktigste endringene er i den siste Vue-utgivelsen.

Sammensetning API

Vi kan utvilsomt kalle det splitter nye Composition API for et faktisk gjennombrudd. Du kan lage komponenter på en helt annen måte. Rammeverkets tilnærming er betydelig forskjellig fra den tidligere versjonen. Med Vue 3-kunngjøringene ble vi introdusert for det nye Composition API-konseptet. Vue-samfunnet ble opphisset. Da var ikke brukerne glad i disse endringene, siden de virket for drastiske. Alt fordi applikasjonene basert på Vue.js 2 ville bli inkompatible med nye Vue.js.

Utviklere fryktet at rammeutviklingsteamet ikke har en klar og stødig visjon for videre vekst. Ikke rart de allerede har sett et lignende scenario tidligere med angular.js framework fra Google. Deretter har utviklere endret konseptet så drastisk at det i stedet for å lage sin nye utgivelsesversjon, ble et helt eget rammeverk – Angular.

Imidlertid viste det seg senere at frykten ikke holdt vann. Evan You, leder for rammeutviklingsteamet, kunngjorde at tidligere API endrer navn til Options API, og de vil fortsette å gi teknisk støtte til utviklere. Det er strålende nyheter, siden vi fortsatt kan lage applikasjoner i Vue 3, med full bakoverkompatibilitet, og nyte fordelene med Composition API.

Du kan spørre hva disse fordelene er. For det første større fleksibilitet i å arrangere kodelogikk, dens bedre gjenbrukbarhet og forbedret lesbarhet - takket være et mindre antall innrykk. Erfaring har vist at større applikasjoner, basert på Vue.js versjon 2, var mye vanskeligere å vedlikeholde og utvikle. Diagnostisering av programvarefeil var litt av en utfordring. Noen utviklere klaget over reaktivitetsproblemer. Med dette i tankene satte Evan You seg for å endre tilnærmingen for å endre måten å lage komponenters logikk på. Inspirasjonen hans kom fra andre populære rammeverk, som React eller Svelte. En av de mange ideene han hadde var for eksempel ved å introdusere strukturer som forvirrende ligner på React Hooks.

For å vise deg hvordan i det virkelige liv, kan du fleksibelt lage komponentlogikk via Composition API, jeg har laget en budsjettkalkulator med grunnleggende funksjoner. Den har et innebygd søk, kan holde og beregne dine nåværende utgifter.

Applikasjonen er ikke annet enn et enkelt skjema som består av felt som inneholder forskjellige data. Du kan enkelt legge til en ekstra utgift, sette inn navn og pris. Som et resultat oppretter du en utgiftsliste. Jeg har lagt til en enkel logikk for å filtrere utgifter etter navn og beregne totalen. Jeg valgte disse to funksjonene med vilje for å vise forskjellene mellom driften av den nye Composition API og den forrige Options API. La oss nå se på komponentlogikken jeg har laget med Options API.

Skjermbildet viser basiskomponentlogikken. I Options API måtte utvikleren skille kodelogikken, ikke etter funksjonaliteten, men ved å gruppere objekter. For eksempel var de ansvarlige for applikasjonens tilstand, metoder, beregnede og overvåkede verdier og andre. Som et resultat brukte den en del innenfor den større komponenten for spesifikke funksjoner ble ganske enkelt spredt over hele komponenten. Du kan se det her. Delehåndteringskostnadene er merket med grønt, mens de i oransje fungerer med søkefunksjonen. Vi kan godt se at koden ikke er organisert etter funksjonen, men komponenter flettes sammen. Med større komponenter fungerer det dårlig da koden blir uleselig. Enhver utvikler som jobber med en spesifikk funksjonalitet må "hoppe" innenfor koden.

Jeg vil gjerne tilby min løsning på problemet via Composition API.

I skjermbildet er de grønne kodedelene utgifter mens de oransje gjelder selve søket. Det du ser med en gang er den bedre kodeorganiseringen - ikke fragmentert, kodefargen tilsvarer en funksjon. Hvordan oppnå det? Du tar et komplisert Vue-forekomstobjekt med et sett med felt (data, metoder, beregnet og overvåking) og erstatter det med en enkelt oppsettsfunksjon.

Vi kan legge all kodelogikken inne i oppsettfunksjonen, som et resultat trenger du ikke å referere til dataene og metodene til en komponent ved å bruke "dette" nøkkelordet. Dette er en ganske praktisk måte å nærme seg det på. Mange feil i JavaScript-applikasjoner kom fra ingen forståelse av "dette" og hvordan og i hvilken kontekst det fungerer i koden.

Ved å bruke denne typen konstruksjon, i motsetning til en mer objektorientert, kan vi lettere gjenbruke koden vår. I skjermbildet ovenfor har kodesøkelogikken blitt flyttet til den tilpassede useSearch-kroken.

Ved å gjøre det kan vi bruke objektsøkefunksjonalitet på nytt også i andre komponenter uten kodeduplisering. Den forrige rammeversjonen krevde bruk av mixins for å gjøre det. Likevel hadde den mange begrensninger strengt knyttet til arv i objektorientert programmering. Det nye Composition API oppnår dette målet til tross for mangel på blandinger. Som et resultat gir Composition API nå alle utviklere mye større fleksibilitet for å lage komponenter og kodeorganisasjonsstruktur.

Teleporter

Funksjonen lar deg gjengi hvilken som helst komponentdel, bokstavelig talt hvor som helst i DOM-treet. Så langt var malen definert inne i komponenten fanget i den, noe som er en god praksis i programmering. Noen ganger kan det imidlertid hende du må bruke en viss del av en komponent et annet sted, altså selve navnet. Det er ekstremt nyttig når du jobber med alle slags modaler, varsler eller popup-vinduer. Ettersom Teleporten blir, la oss si en innebygd komponent av Vue 3, vil gjengivelsen bli ekstremt praktisk og ingen eksterne patcher vil være nødvendig.

Komponenter med flere rot

I den forrige Vue-versjonen sto vi overfor en begrensning knyttet til å starte komponentmalen. Du måtte begynne en mal med bare ett DOM-grunnelement. Noen ganger kan en slik ekstra tag-innpakning binde alle elementene våre sammen i strukturen – ikke alltid det var nødvendig eller fornuftig. Det økte DOM-størrelsen. I Vue 3 kan du fritt kode, siden det ikke krever noen ekstra tagg for å pakke inn andre tagger. Se selv og sammenlign.

Vue 2-komponentmal

Vue 3-komponentmal

Forbedret typeskrift

Kildekoden i Vue 3 er ny og omskrevet i Typescript. Hvis du husker, var det litt problematisk å bruke Typescript (Vue 2), på grunn av den objektorienterte Options API. Som et resultat måtte de fleste utviklere som ønsket å fortsette med å skrive, bruke Vue Class Component-pakken. Når den først ble brukt, var det mulig å lage en klassebasert komponent mye enklere i Typescript. Det nye versjonsrammeverket trenger ingen tilleggspakke. Den bruker Composition API, noe som gjør livet ditt mye enklere.

Spenning

Noen ganger må du laste inn visse komponenter og data asynkront. Vanlig praksis var å erklære et spesielt boolsk flagg. Den vil lagre informasjon om komponentdatainnlastingstilstanden. Likevel er det litt overflødig arbeid. Først må dataene lastes inn i en komponent, så vil vi vente på at en laster skal vises eller se et varsel om at datalasting fortsatt venter. I Vue 3 var det å legge til Suspense-komponenten for å forenkle hele prosessen.

Nå, prosessen ble automatisert, er det ikke nødvendig å bruke boolske flagg som holder lastestatus. I stedet kan du bruke to spesielle spor inne i Suspense-komponenten. Tidligere måtte vi definere forhold og atferd under og etter asynkron datainnlasting for både komponenter og data.

Se, spenningskomponenten på jobb:

Buntstørrelsesoptimalisering og effektivitet

Siden arbeidet med Vue 3 begynte, har skaperne av rammeverk fokusert på to mål – reduksjon av hovedpakkestørrelse og økt effektivitet. De oppnådde det ved å separere rammeverkets kjerne, noe som bidro til å komprimere buntens størrelse til 10 kb (to ganger mindre enn Vue 2).

Effektiviteten økte også ved å introdusere en avansert tilnærming til treristing. Hvis du bruker en spesifikk rammefunksjon, vil dens logiske kode ikke bli brukt av hovedpakken i motsetning til Vue 2. Derfor forårsaket forbedret modularitet betydelig reduksjon i produksjonsbuntens størrelse, spesielt i større apper.

Migrasjon til Vue 3

Den gode nyheten er at migrering til versjon 3 ikke burde være en smerte. På grunn av bakoverkompatibilitet med Options API, har komponenter vi opprettet i Vue 2 støtte og bør fungere sømløst i Vue 3. Vi kan enkelt migrere applikasjonen vår til Vue 3 uten å omarbeide noen av komponentene.

Foreløpig har begge API-ene full støtte, og valget er ditt. Du kan begynne å bruke Composition API, mens du omskriver komponentene dine. Hvis du ble knyttet til den gamle Vue 2, kan du bruke den også.

Å oppsummere

Vue 3 er et steg opp og frem. Utviklerne ble sterkt inspirert av andre populære løsninger i Javascript-fellesskapet og den stadig mer populære funksjonelle programmeringsmetoden. Vi vet foreløpig ikke hvor mange brukere som vil jobbe med det nye API-et. Det vil avhenge av personlige preferanser. Vue 3 var det ultimate svaret på problemer knyttet til å kjøre store applikasjoner. Med tiden vil vi vurdere om disse løsningene fungerte i store applikasjonsdistribusjoner.

I mellomtiden bør vi observere Vue-tilnærmingen. Høy sjanse, den vil bli like populær som React eller Angular. For øyeblikket omfatter det Vue 3-orienterte økosystemet Vuex, Vue Router og Vue Devtools. Selve rammeverket som dets verktøy er stabilt og godt utviklet. Vue-rammeverket er modent og gjør en god programvarekandidat for å utvikle ferske og utfordrende prosjekter. Nå er jeg ganske overbevist om at Vue-rammeverket har en lys fremtid foran Vue. Snart nok burde vi vite det.