Aceasta postare de blog este o contributie la Vuecember 2020 la sum.cumo, cu o gramada de subiecte interesante pana la 24.12.2020.

Cand creati aplicatii universale in loc de aplicatii cu o singura pagina (SPA-uri), exista o multime de lucruri de luat in considerare. Codul este acum executat nu numai in browser, ci si pe un server Node.

Array

js. Acest lucru inseamna, de exemplu, ca trebuie sa scriem cod universal pentru a evita erori precum „Uncaught ReferenceError: fereastra nu este definita”.

De asemenea, trebuie sa ne facem griji cu privire la hidratarea pe partea clientului, configurarea constructiei, stocarea in cache si multe altele, care sunt intr-o oarecare parte acoperite in Ghidul oficial Vue SSR.

Din experienta mea, unul dintre subiectele cele mai predispuse la erori este procesul de hidratare pe partea clientului. Eu si Sven Wager am scris deja o postare pe blog despre cum sa intelegem si sa rezolvam erorile de hidratare in Vue.js.

Array

Alex Lichter a scris un ghid despre ce se face atunci cand hidratarea Vue esueaza.

Cealalta categorie de erori frustrante si greu de rezolvat apare pe serverul insusi in timpul procesului de redare pe partea serverului.

In timp ce browserul gestioneaza de obicei o singura aplicatie, serverul gestioneaza mai multe cereri in paralel, precum si succesiv. Intr-un mediu Node.js, aceste cereri nu sunt procesate in fire izolate, ci intr-un singur fir cu o singura stare globala. Ca urmare, erorile apar atunci cand starea nu este corect separata intre cereri.

Array

Apar si erori, atunci cand statul global este extins in mod repetat la fiecare cerere.

In aceasta postare de blog as dori sa ofer o intelegere mai profunda a ciclului de viata al serverului si a relatiei dintre diferite contexte de executie pentru a va ajuta sa identificati si sa remediati problemele comune.

Mediul prietenos al browserului.

Intr-un mediu de browser exista de obicei exact o aplicatie, o instanta VueRouter si o instanta Vuex. Nav, Router etc.

sunt Componente care sunt copii ai componentei radacina cunoscuta si ca aplicatie.

Acest lucru face o multime de lucruri destul de simple, cum ar fi obtinerea instantei Vuex dintr-un global inainte de fiecare carlig de la VueRouter:

Motivul pentru care putem folosi singletonii de stare este ca exista exact o instanta la un moment dat si nu este impartasita o alta cerere.

In aplicatia Server-Side Rendering, lucrurile arata destul de diferit.

Contextele intr-o aplicatie de redare pe partea de server

Contextul global se comporta similar cu ceea ce suntem obisnuiti dintr-un mediu de browser. In fiecare proces node.js, exista una globala, la fel cum exista o fereastra, un mediu de browser. Fiecare modul JavaScript incarcat este un singleton de stare in acest context global.

Instante de obiecte de stare pe cerere

Fara a modifica structura codului nostru, acest lucru ar insemna ca toate cererile au aceleasi singletoni de stare. Conform exemplului de mai sus, toate cererile concurente ar avea intotdeauna aceeasi stare de autentificare.

Nota: in majoritatea aplicatiilor autentificarea nu va fi gestionata in randarea server-side.

Solicitarile redate simultan ar putea interfera una cu cealalta, in timp ce cererile ulterioare nu ar incepe cu o stare „proaspata”, ci orice ar fi ramas in urma.

Aplicatie sparta cu apolloProvider partajat.

Odata am experimentat-o ​​pe cea din urma cu VueApollo, care este un plugin Vue pentru integrarea GraphQL.

In acest caz, nu am creat un apolloProvider pentru fiecare cerere si apollo InMemoryCache a continuat sa creasca si sa creasca, ceea ce a avut doua efecte secundare majore.

Primul a fost ca am trimis o incarcare utila in crestere cu memoria cache completa la browser pentru hidratarea laterala a clientului.

In plus, cache-ul preumplut a ascuns faptul ca nu am preluat corect toate datele externe la fiecare incarcare a paginii – care a fost inainte de introducerea carligului serverPrefetch. Cand serverul a repornit si cache-ul a fost golit efectiv, majoritatea paginilor au fost goale, de asemenea, deoarece majoritatea datelor nu au putut fi preluate la timp.

Ghidul Vue SSR explica modul de schimbare a structurii codului sursa pentru a evita singletonii de stare. In aplicatiile NuxtJS, „contextul” ajuta la accesarea instantelor de obiecte de stare care altfel ar fi inaccesibile, deoarece acestea nu pot fi pur si simplu „importate”.

Cu toate acestea, aceasta nu este singura capcana in care s-ar putea cadea: exista mai multi singletoni de stat in jur. Cum ar fi Vue in sine.

Obiecte globale de stare

Vue este un obiect cu stare in sine. Stocheaza plugin-uri instalate, optiuni de mixere si active, cum ar fi componente si decoratori. Acest lucru poate duce la probleme daca acest obiect cu stare nu este modificat doar la pornirea aplicatiei, ci la fiecare cerere .

Comparati aceste trei cazuri:

In primul caz, este instalat un plugin – atat. Exista o schimbare a starii globale si ramane asa pentru toate cererile care vor veni.

In al doilea caz, un plugin este creat o data , dar este instalat la fiecare cerere . Aceasta ar putea fi o problema, dar Vue.use verifica daca un plugin este deja instalat si, prin urmare, pluginul este instalat numai o singura data.

Cu toate acestea, daca pluginul este creat pe cerere , verificarea implementata in Vue.use nu poate identifica pluginul deja instalat si instaleaza suplimentar noul plugin.

Pluginul din acest exemplu instaleaza apoi un mixin global, fuzionand cu optiunile curente. Acest lucru poate duce la tot felul de regresii de la probleme de performanta la memorie si asa cum am experimentat chiar si o „eroare maxima a stivei de apeluri”.

Daca sunteti constienti de acest ciclu de viata si instalati pluginuri, mixuri si active la momentul potrivit, sunteti deja destul de sigur. NuxtJS va ajuta cu asta, atata timp cat nu utilizati callback-ul furnizat pluginurilor NuxtJS pentru a schimba singletonul Vue.

Ultimul lucru care ti-ar putea impiedica, mai ales intr-o configurare de dezvoltare, unde codul este recompilat si reexecutat, este bundleRenderer.

BundleRenderer

BundleRenderer este ceea ce face de fapt redarea unui sir HTML. Acest lucru se poate face pentru a genera pagini statice sau pentru procesarea unei cereri HTTP.

Exista o setare care afecteaza obiectele care au stat in context sunt create in: runInNewContext. Poate fi setat la fals, „o data” sau adevarat – fiecare avand ca rezultat un comportament diferit al aplicatiei.

Daca runInNewContext este setat la false, nu trebuie sa va faceti griji. Nu exista o „cutie” suplimentara.

Daca bundleRenderer este configurat sa rulezeInNewContext: „o data”, exista cateva avertismente care sunt descrise in documentele oficiale. Cu toate acestea, acestea nu au legatura cu ceea ce s-a discutat mai sus.

Daca runInNewContext este setat la true, care este setarea implicita pentru un server de dezvoltare NuxtJS , comportamentul este destul de diferit:

[…] pentru fiecare randare, randatorul de pachete va crea un nou context V8 si va executa din nou intregul pachet.

Aceasta inseamna ca ceea ce pare un obiect global din interiorul pachetului este recreat pentru fiecare cerere. Acest lucru nu vine doar cu unele costuri de performanta, ci si schimba comportamentul aplicatiei.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR