Cum să migrați de la jQuery la Next.js

Publicat: 2022-03-10
Rezumat rapid ↬ În acest articol, aruncăm o privire mai atentă asupra diferitelor abordări și strategii cu privire la modul în care putem migra o aplicație web care utilizează framework-ul jQuery și începem să folosim unul dintre cele mai tari framework-uri React de pe piață: Next.js.

Când jQuery a apărut în 2006, o mulțime de dezvoltatori și organizații au început să-l adopte pentru proiectele lor. Posibilitatea de a extinde și de a manipula DOM -ul oferit de biblioteca este mare și avem, de asemenea, multe plugin-uri pentru a adăuga comportament paginilor noastre în cazul în care trebuie să facem sarcini care nu sunt acceptate de biblioteca principală jQuery. A simplificat o mare parte din munca dezvoltatorilor și, în acel moment, a făcut din JavaScript un limbaj puternic pentru a crea aplicații web sau aplicații cu o singură pagină.

Rezultatul popularității jQuery este măsurabil și astăzi: aproape 80% dintre cele mai populare site-uri web din lume încă îl folosesc. Unele dintre motivele pentru care jQuery este atât de popular sunt:

  • Suporta manipularea DOM.
  • Oferă manipulare CSS.
  • Funcționează la fel pe toate browserele web.
  • Acesta include metode de evenimente HTML.
  • Ușor de creat apeluri AJAX.
  • Efecte și animații ușor de utilizat.

De-a lungul anilor, JavaScript s-a schimbat mult și a adăugat câteva funcții pe care nu le aveam în trecut. Odată cu redefinirea și evoluția ECMAScript, unele dintre funcționalitățile oferite de jQuery au fost adăugate la caracteristicile standard JavaScript și acceptate de toate browserele web. În acest caz, unele dintre comportamentele oferite de jQuery nu mai erau necesare , deoarece putem face aceleași lucruri cu JavaScript simplu.

Pe de altă parte, a început să apară un nou mod de a gândi și de a proiecta interfețele utilizator. Framework-uri precum React, Angular sau Vue le permit dezvoltatorilor să creeze aplicații web bazate pe componente funcționale reutilizabile. React, adică, funcționează cu „DOM-ul virtual”, care este o reprezentare DOM în memorie, în timp ce jQuery interacționează direct cu DOM-ul , într-un mod mai puțin performant. De asemenea, React oferă funcții interesante pentru a facilita dezvoltarea anumitor funcții, cum ar fi managementul de stat. Cu această nouă abordare și cu popularitatea pe care aplicațiile cu o singură pagină au început să o câștige, mulți dezvoltatori au început să folosească React pentru proiectele lor de aplicații web.

Și dezvoltarea front-end a evoluat și mai mult, cu cadre create pe deasupra altor cadre. Acesta este cazul, de exemplu, al Next.js. După cum probabil știți, este un cadru React open-source care oferă funcții pentru a genera pagini statice, a crea pagini randate pe server și a combina ambele tipuri în aceeași aplicație. De asemenea, permite crearea de API-uri fără server în cadrul aceleiași aplicații.

Există un scenariu curios: chiar dacă aceste framework-uri frontend sunt din ce în ce mai populare de-a lungul anilor, jQuery este încă adoptat de marea majoritate a paginilor web. Unul dintre motivele pentru care se întâmplă acest lucru este că procentul de site-uri web care folosesc WordPress este foarte mare, iar jQuery este inclus în CMS . Un alt motiv este că unele biblioteci, cum ar fi Bootstrap, au o dependență de jQuery și există câteva șabloane gata de utilizare care îl folosesc și pluginurile sale.

Dar un alt motiv pentru această cantitate de site-uri web care utilizează jQuery este costul migrării unei aplicații web complete la un nou cadru. Nu este ușor, nu este ieftin și consumă mult timp. Dar, în cele din urmă, lucrul cu instrumente și tehnologii noi aduce o mulțime de beneficii: asistență mai largă, asistență comunitară, experiență mai bună pentru dezvoltatori și ușurință de a atrage oamenii să lucreze la proiect.

Există multe scenarii în care nu avem nevoie (sau nu dorim) să urmăm arhitectura pe care ni-o impun framework-uri precum React sau Next.js și asta este în regulă. Cu toate acestea, jQuery este o bibliotecă care conține o mulțime de cod și caracteristici care nu mai sunt necesare. Multe dintre caracteristicile oferite de jQuery pot fi realizate folosind funcții native JavaScript moderne și, probabil, într-un mod mai performant.

Să discutăm despre cum am putea înceta să mai folosim jQuery și să migram site-ul nostru într-o aplicație web React sau Next.js.

Definiți strategia de migrație

Avem nevoie de o bibliotecă?

În funcție de caracteristicile aplicației noastre web, am putea chiar să avem cazul în care un cadru nu este cu adevărat necesar. După cum am menționat anterior, mai multe caracteristici jQuery au fost incluse (sau cel puțin una foarte asemănătoare) celor mai recente versiuni standard web. Deci, avand in vedere ca:

  • Modelul $(selector) din jQuery poate fi înlocuit cu querySelectorAll() .

In loc sa faci:

 $("#someId");

Putem să facem:

 document.querySelectorAll("#someId");
  • Avem acum proprietatea Element.classList dacă vrem să manipulăm clasele CSS.

In loc sa faci:

 $(selector).addClass(className);

Putem să facem:

 element.classList.add(className);
  • Multe animații pot fi realizate direct folosind CSS, în loc să implementeze JavaScript.

In loc sa faci:

 $(selector).fadeIn();

Putem să facem:

 element.classList.add('show'); element.classList.remove('hide');

Și aplică câteva stiluri CSS:

 .show { transition: opacity 400ms; } .hide { opacity: 0; }
  • Avem acum funcția addEventListener dacă vrem să gestionăm evenimente.

In loc sa faci:

 $(selector).on(eventName, eventHandler);

Putem să facem:

 element.addEventListener(eventName, eventHandler);
  • În loc să folosim jQuery Ajax, putem folosi XMLHttpRequest .

In loc sa faci:

 $.ajax({ type: 'POST', url: '/the-url', data: data });

Putem să facem:

 var request = new XMLHttpRequest(); request.open('POST', '/the-url', true); request.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8'); request.send(data);

Pentru mai multe detalii, puteți arunca o privire la aceste fragmente de cod JavaScript Vanilla.

Identificați Componentele

Dacă folosim jQuery în aplicația noastră, ar trebui să avem conținut HTML care este generat pe serverul web și cod JavaScript care adaugă interactivitate paginii. Probabil că adăugăm handlere de evenimente la încărcarea paginii care vor manipula DOM atunci când se întâmplă evenimentele, probabil actualizând CSS-ul sau stilul elementelor. De asemenea, am putea apela servicii de backend pentru a executa acțiuni, care pot afecta DOM-ul paginii sau chiar o pot reîncărca.

Ideea ar fi să refactorizezi codul JavaScript care trăiește în pagini și să construiești componente React. Acest lucru ne va ajuta să unim codul conex și să compunem elemente care vor face parte dintr-o compoziție mai mare. Făcând acest lucru, vom putea, de asemenea, să gestionăm mai bine starea aplicației noastre. Analizând interfața aplicației noastre, ar trebui să o împărțim în părți dedicate unei anumite sarcini, astfel încât să putem crea componente pe baza acesteia.

Dacă avem un buton:

 <button>Click</button>

Cu următoarea logică:

 var $btnAction = $("#btn-action"); $btnAction.on("click", function() { alert("Button was clicked"); });

Îl putem migra la o componentă React:

 import React from 'react'; function ButtonComponent() { let handleButtonClick = () => { alert('Button clicked!') } return <button onClick={handleButtonClick}>Click</button> }

Dar ar trebui să evaluăm și modul în care se va realiza procesul de migrare, deoarece aplicația noastră funcționează și este utilizată și nu vrem să o afectăm (sau, cel puțin, să o afectăm cât mai puțin posibil).

Migrație bună

O migrare bună este aceea în care toate părțile aplicației sunt migrate complet către noul cadru sau tehnologie. Acesta ar fi scenariul ideal pentru aplicația noastră, deoarece am menține sincronizate toate părțile și am folosi un instrument unificat și o versiune unică de referință.

O migrare bună și completă include de obicei o rescrie completă a codului aplicației noastre și asta are sens. Dacă construim o aplicație de la zero, avem posibilitatea de a decide ce direcție vrem să luăm cu noul cod. Am putea folosi un nou punct de vedere asupra sistemelor și fluxului nostru de lucru existent și să creăm o aplicație complet nouă, cu cunoștințele pe care le avem în acest moment, mai complete decât cele pe care le aveam când am creat prima aplicație web.

Dar o rescrie completă are unele probleme. În primul rând, necesită mult timp. Cu cât aplicația este mai mare, cu atât vom avea nevoie de mai mult timp pentru a o rescrie. O altă problemă este cantitatea de muncă și cantitatea de dezvoltatori de care este nevoie. Și, dacă nu facem o migrare progresivă, trebuie să ne gândim la cât timp va fi indisponibilă aplicația noastră.

În mod normal, o rescrie completă poate fi realizată cu proiecte mici, proiecte care nu se schimbă frecvent sau aplicații care nu sunt atât de critice pentru afacerea noastră.

Migrație rapidă

O altă abordare este împărțirea aplicației în părți sau bucăți. Migrem aplicația parte cu parte și eliberăm acele părți când sunt gata. Deci, am migrat părți ale aplicației noastre disponibile pentru utilizatori și coexistând cu aplicația noastră de producție existentă.

Cu această migrare treptată, oferim utilizatorilor funcții separate ale proiectului nostru într-un mod mai rapid, deoarece nu trebuie să așteptăm ca aplicația completă să fie rescrisă. De asemenea, primim feedback mai rapid de la utilizatori, ceea ce ne permite să detectăm mai devreme erori sau probleme.

Dar o migrare treptată ne determină să avem diferite instrumente, biblioteci, dependențe și cadre. Sau chiar ar putea fi nevoiți să acceptăm versiuni diferite de la același instrument. Acest suport extins ar putea aduce conflicte aplicației noastre.

Am putea chiar să avem probleme dacă aplicăm politici în sfera globală, deoarece fiecare dintre părțile migrate ar putea funcționa într-un mod diferit, dar fiind afectată de codul care stabilește parametri globali sistemului nostru. Un exemplu în acest sens este utilizarea unei logici în cascadă pentru stilul CSS.

Imaginați-vă că lucrăm cu diferite versiuni de jQuery în aplicația noastră web, deoarece am adăugat funcționalități din versiuni mai noi la modulele care au fost create ulterior. Cât de complicat ar fi să migrem toată aplicația noastră la o versiune mai nouă de jQuery? Acum, imaginați-vă același scenariu, dar migrând la un cadru complet diferit, cum ar fi Next.js. Asta poate fi complicat.

Migrația Frankenstein

Denys Mishunov a scris un articol pe Smashing Magazine prezentând o alternativă la aceste două idei de migrație, încercând să obțină cele mai bune dintre cele două abordări anterioare: Migrația Frankenstein. Acesta bazează procesul de migrare în două componente principale: Microservicii și Componente Web.

Procesul de migrare constă dintr-o listă de pași de urmat:

1. Identificați microservicii

Pe baza codului aplicației noastre, ar trebui să o împărțim în părți independente care sunt dedicate unei singure lucrări mici. Dacă ne gândim să folosim React sau Next.js, am putea lega conceptul de microservicii de diferitele componente pe care le avem.

Să ne gândim la o aplicație pentru lista de produse alimentare ca exemplu. Avem o listă de lucruri de cumpărat și o intrare pentru a adăuga mai multe lucruri la listă. Deci, dacă vrem să ne împărțim aplicația în părți mici, ne-am putea gândi la o componentă „listă de articole” și la o componentă „adăugați element”. Făcând acest lucru, putem separa funcționalitatea și marcajul legat de fiecare dintre acele părți în diferite componente React.

Pentru a confirma că componentele sunt independente, ar trebui să putem elimina una dintre ele din aplicație, iar celelalte nu ar trebui să fie afectate de asta. Dacă primim o eroare când eliminăm marcajul și funcționalitatea dintr-un serviciu, nu identificăm corect componentele sau trebuie să refactorăm modul în care funcționează codul nostru.

2. Permite accesul de la gazdă la străin

„Gazdă” este aplicația noastră existentă. „Alien” este cel pe care vom începe să îl creăm, cu noul cadru. Ambele ar trebui să funcționeze independent, dar ar trebui să oferim acces de la Gazdă la Alien. Ar trebui să putem implementa oricare dintre cele două aplicații fără a o întrerupe pe cealaltă, dar păstrând comunicarea între ele.

3. Scrieți o componentă extraterestră

Rescrieți un serviciu din aplicația noastră Gazdă în aplicația noastră Alien, folosind noul cadru. Componenta ar trebui să urmeze același principiu de independență pe care l-am menționat anterior.

Să revenim la exemplul listei de produse alimentare. Am identificat o componentă „adăugați articol”. Cu jQuery, marcajul componentei va arăta cam așa:

 <input class="new-item" />

Și codul JavaScript/jQuery pentru a adăuga elementele în listă va fi cam așa:

 var ENTER_KEY = 13; $('.new-item').on('keyup', function (e) { var $input = $(e.target); var val = $input.val().trim(); if (e.which !== ENTER_KEY || !val) { return; } // code to add the item to the list $input.val(''); });

În loc de asta, putem crea o componentă AddItem React:

 import React from 'react' function AddItemInput({ defaultText }) { let [text, setText] = useState(defaultText) let handleSubmit = e => { e.preventDefault() if (e.which === 13) { setText(e.target.value.trim()) } } return <input type="text" value={text} onChange={(e) => setText(e.target.value)} onKeyDown={handleSubmit} /> }

4. Scrieți Web Component Wrapper Around Alien Service

Creați o componentă wrapper care importă serviciul nostru Alien tocmai creat și îl redă. Ideea este de a crea o punte între aplicația Gazdă și aplicația Alien. Rețineți că am putea avea nevoie de un pachet de pachete pentru a genera cod JavaScript care funcționează în aplicația noastră actuală, deoarece va trebui să copiem noile noastre componente React și să le facem să funcționeze.

Urmând exemplul listei de produse alimentare, putem crea un fișier AddItem-wrapper.js în proiectul Host. Acest fișier va conține codul care include componenta AddItem deja creată și creează un element personalizat cu el:

 import React from "../alien/node_modules/react"; import ReactDOM from "../alien/node_modules/react-dom"; import AddItem from "../alien/src/components/AddItem"; class FrankensteinWrapper extends HTMLElement { connectedCallback() { const appWrapper = document.createElement("div"); appWrapper.classList.add("grocerylistapp"); ... ReactDOM.render( <HeaderApp />, appWrapper ); … } } customElements.define("frankenstein-add-item-wrapper", FrankensteinWrapper);

Ar trebui să aducem modulele și componentele de nod necesare din folderele aplicației Alien, deoarece trebuie să le importăm pentru a face componenta să funcționeze.

5. Înlocuiți Serviciul Gazdă cu Componenta Web

Această componentă wrapper o va înlocui pe cea din aplicația Host și vom începe să o folosim. Deci, aplicația în producție va fi un amestec de componente Host și componente înfășurate Alien.

În exemplul nostru de aplicație gazdă, ar trebui să înlocuim:

 <input class="new-item" />

Cu

 <frankenstein-add-item-wrapper></frankenstein-add-item-wrapper> ... <script type="module" src="js/AddItem-wrapper.js"></script>

6. Clătiți și repetați

Parcurgeți pașii 3, 4 și 5 pentru fiecare dintre microservicii identificate.

7. Comutați la Alien

Host este acum o colecție de componente wrapper care includ toate componentele web pe care le-am creat în aplicația Alien. Pe măsură ce am convertit toate microserviciile identificate, putem spune că aplicația Alien este terminată și toate serviciile au fost migrate. Trebuie doar să îndreptăm utilizatorii noștri către aplicația Alien acum.

Metoda Frankenstein Migration funcționează ca o combinație între abordările bune și cele rapide. Migrem aplicația completă, dar eliberăm diferitele componente când sunt terminate. Deci, acestea sunt disponibile pentru a fi utilizate mai devreme și evaluate de utilizatorii în producție.

Trebuie să luăm în considerare, totuși, că lucrăm în exces cu această abordare. Dacă dorim să folosim componentele pe care le creăm pentru aplicația noastră Alien, trebuie să creăm o componentă wrapper pe care să o includem în aplicația Host. Acest lucru ne face să petrecem timp dezvoltând codul pentru aceste elemente de înveliș. De asemenea, folosindu-le în aplicația noastră Gazdă, duplicăm includerea codului și a dependențelor și adăugăm cod care va afecta performanța aplicației noastre.

Aplicația Strangler

O altă abordare pe care o putem adopta este Strangularea aplicației moștenite. Identificăm marginile aplicației noastre web existente și, ori de câte ori trebuie să adăugăm funcționalități aplicației noastre, o facem folosind un cadru mai nou până când vechiul sistem este „sugrumat”. Această abordare ne ajută să reducem riscul potențial pe care îl putem experimenta în timpul migrării unei aplicații.

Pentru a urma această abordare, trebuie să identificăm diferite componente, așa cum facem în Frankenstein Migration. Odată ce împărțim aplicația noastră în diferite bucăți de cod imperativ asociat, le împachetăm în noi componente React. Nu adăugăm niciun comportament suplimentar, doar creăm componente React care redă conținutul nostru existent.

Să vedem un exemplu pentru mai multe lămuriri. Să presupunem că avem acest cod HTML în aplicația noastră:

 <div class="accordion"> <div class="accordion-panel"> <h3 class="accordion-header">Item 1</h3> <div class="accordion-body">Text 1</div> </div> <div class="accordion-panel"> <h3 class="accordion-header">Item 2</h3> <div class="accordion-body">Text 2</div> </div> <div class="accordion-panel"> <h3 class="accordion-header">Item 3</h3> <div class="accordion-body">Text 3</div> </div>> </div>

Și acest cod JavaScript (am înlocuit deja funcțiile jQuery cu noi caracteristici standard JavaScript).

 const accordions = document.querySelectorAll(".accordion"); for (const accordion of accordions) { const panels = accordion.querySelectorAll(".accordion-panel"); for (const panel of panels) { const head = panel.querySelector(".accordion-header"); head.addEventListener('click', () => { for (const otherPanel of panels) { if (otherPanel !== panel) { otherPanel.classList.remove('accordion-expanded'); } } panel.classList.toggle('accordion-expanded'); }); } }

Aceasta este o implementare comună a unei componente accordion pentru JavaScript. Deoarece vrem să introducem React aici, trebuie să împachetăm codul nostru existent cu o nouă componentă React:

 function Accordions() { useEffect(() => { const accordions = document.querySelectorAll(".accordion") for (const accordion of accordions) { const panels = accordion.querySelectorAll(".accordion-panel") for (const panel of panels) { const head = panel.querySelector(".accordion-header") head.addEventListener("click", () => { for (const otherPanel of panels) { if (otherPanel !== panel) { otherPanel.classList.remove("accordion-expanded") } } panel.classList.toggle("accordion-expanded") }); } } }, []) return null } ReactDOM.render(<Accordions />, document.createElement("div"))

Componenta nu adaugă niciun comportament sau caracteristică nouă. Folosim useEffect deoarece componenta a fost montată în document. De aceea funcția returnează null deoarece cârligul nu trebuie să returneze o componentă.

Deci, nu am adăugat nicio funcționalitate nouă la aplicația noastră existentă, dar am introdus React fără a-i schimba comportamentul. De acum înainte, ori de câte ori adăugăm noi funcții sau modificări la codul nostru, o vom face folosind noul cadru selectat.

Redare pe partea client, Redare pe server sau generare statică?

Next.js ne oferă posibilitatea de a alege modul în care dorim să redăm fiecare pagină a aplicației noastre web. Putem folosi redarea pe partea client pe care React ne-o oferă deja pentru a genera conținutul direct în browserul utilizatorului. Sau, putem reda conținutul paginii noastre pe server folosind randarea pe server. În cele din urmă, putem crea conținutul paginii noastre în timpul construirii utilizând generarea statică.

În aplicația noastră, ar trebui să încărcăm și să redăm cod la încărcarea paginii, înainte de a începe să interacționăm cu orice bibliotecă sau cadru JavaScript. Este posibil să folosim un limbaj sau o tehnologie de programare de randare pe server, cum ar fi ASP.NET, PHP sau Node.js. Putem beneficia de caracteristicile Next.js și putem înlocui metoda noastră actuală de randare cu metoda de randare Next.js pe server . Făcând acest lucru, păstrăm tot comportamentul în interiorul aceluiași proiect, care funcționează sub umbrela cadrului selectat. De asemenea, păstrăm logica paginii noastre principale și a componentelor React în cadrul aceluiași cod care generează tot conținutul necesar pentru pagina noastră.

Să ne gândim la o pagină de tablou de bord ca exemplu. Putem genera tot markupul inițial al paginii în momentul încărcării, în server, în loc să fie nevoie să îl generăm cu React în browserul web al utilizatorului.

 const DashboardPage = ({ user }) => { return ( <div> <h2>{user.name}</h2> // User data </div> ) } export const getServerSideProps = async ({ req, res, params }) => { return { props: { user: getUser(), }, } }, }) export default DashboardPage

Dacă marcajul pe care îl redăm la încărcarea paginii este previzibil și se bazează pe date pe care le putem prelua în timpul construirii, generarea statică ar fi o alegere bună. Generarea de active statice în timpul construirii va face aplicația noastră mai rapidă, mai sigură, scalabilă și mai ușor de întreținut. Și, în cazul în care trebuie să generăm conținut dinamic pe paginile aplicației noastre, putem folosi redarea React la nivelul clientului pentru a prelua informații din servicii sau surse de date.

Imaginați-vă că avem un site de blog, cu multe postări pe blog. Dacă folosim Static Generation, putem crea un fișier generic [blog-slug].js în aplicația noastră Next.js și, adăugând următorul cod, vom genera toate paginile statice pentru postările blogului nostru în timpul construirii.

 export const getStaticPaths = async () => { const blogPosts = await getBlogPosts() const paths = blogPosts.map(({ slug }) => ({ params: { slug, }, })) return { paths, fallback: false, } } export const getStaticProps = async ({ params }) => { const { slug } = params const blogPost = await getBlogPostBySlug(slug) return { props: { data: JSON.parse(JSON.stringify(blogPost)), }, } }

Creați un API utilizând rute API

Una dintre caracteristicile grozave pe care Next.js le oferă este posibilitatea de a crea rute API. Cu ele, ne putem crea propriile funcții fără server folosind Node.js. De asemenea, putem instala pachete NPM pentru a extinde funcționalitatea. Un lucru interesant este că API-ul nostru va lăsa în același proiect/aplicație ca și frontend-ul nostru, așa că nu vom avea probleme CORS.

Dacă menținem un API care este apelat din aplicația noastră web folosind funcționalitatea jQuery AJAX, le-am putea înlocui folosind API Routes . Făcând acest lucru, vom păstra toată baza de cod a aplicației noastre în același depozit și vom simplifica implementarea aplicației noastre. Dacă folosim un serviciu terță parte, putem folosi rute API pentru a „masca” adresele URL externe.

Am putea avea o rută API /pages/api/get/[id].js care returnează datele pe care le folosim pe pagina noastră.

 export default async (req, res) => { const { id } = req.query try { const data = getData(id) res.status(200).json(data) } catch (e) { res.status(500).json({ error: e.message }) } }

Și apelați-l din codul paginii noastre.

 const res = await fetch(`/api/get/${id}`, { method: 'GET', }) if (res.status === 200) { // Do something } else { console.error(await res.text()) }

Implementați în Netlify

Netlify este o platformă completă care poate fi utilizată pentru automatizarea, gestionarea, construirea, testarea, implementarea și găzduirea aplicațiilor web. Are o mulțime de caracteristici care fac dezvoltarea de aplicații web moderne mai ușoară și mai rapidă. Câteva puncte importante ale Netlify sunt:

  • Platformă globală de găzduire CDN,
  • Suport pentru funcții fără server,
  • Implementați previzualizări pe baza solicitărilor de extragere Github,
  • Webhook-uri,
  • Rollback instantanee,
  • Controlul accesului bazat pe roluri.

Netlify este o platformă excelentă pentru a gestiona și găzdui aplicațiile noastre Next.js și este destul de simplu să implementezi o aplicație web cu ea.

În primul rând, trebuie să urmărim codul aplicației Next.js într-un depozit Git. Netlify se conectează la GitHub (sau la platforma Git pe care o preferăm) și ori de câte ori se introduce o modificare într-o ramură (un commit sau o cerere de tragere), va fi declanșată o sarcină automată de „construire și implementare”.

Odată ce avem un depozit Git cu codul aplicației noastre, trebuie să creăm un „Site Netlify” pentru acesta. Pentru a face acest lucru, avem două opțiuni:

  1. Folosind Netlify CLI
    După ce instalăm CLI ( npm install -g netlify-cli ) și ne conectăm la contul nostru Netlify ( ntl login ), putem merge la directorul rădăcină al aplicației noastre, rulăm ntl init și urmam pașii.
  2. Folosind aplicația web Netlify
    Ar trebui să mergem la https://app.netlify.com/start. Conectați-vă la furnizorul nostru Git, alegeți depozitul aplicației noastre din listă, configurați câteva opțiuni de compilare și implementați.

Pentru ambele metode, trebuie să luăm în considerare că comanda noastră de compilare va fi next build , iar directorul nostru de implementat este out .

În cele din urmă, pluginul Essential Next.js este instalat automat, ceea ce ne va permite să implementăm și să folosim rute API, rute dinamice și Modul de previzualizare. Și gata, avem aplicația noastră Next.js în funcțiune într-un serviciu de găzduire CDN rapid și stabil.

Concluzie

În acest articol, am evaluat site-urile web folosind biblioteca jQuery și le-am comparat cu noi cadre de tip frontend precum React și Next.js. Am definit cum am putea începe o migrare, în cazul în care ne avantajează, către un instrument mai nou. Am evaluat diferite strategii de migrare și am văzut câteva exemple de scenarii pe care le-am putea migra către proiecte de aplicații web Next.js. În cele din urmă, am văzut cum să implementăm aplicația noastră Next.js pe Netlify și să o punem în funcțiune.

Lectură suplimentară și resurse

  • Migrația Frankenstein: abordare agnostică a cadrului
  • Eliminarea jQuery din interfața GitHub.com
  • Noțiuni introductive cu Next.js
  • Cum să implementați site-urile Next.js pe Netlify
  • Articole Next.js în Blogul Netlify