Jak przeprowadzić migrację z jQuery do Next.js

Opublikowany: 2022-03-10
Krótkie podsumowanie ↬ W tym artykule przyjrzymy się bliżej różnym podejściom i strategiom migracji aplikacji internetowej korzystającej z frameworka jQuery i zaczniemy korzystać z jednego z najfajniejszych frameworków React na rynku: Next.js.

Kiedy jQuery pojawiło się w 2006 roku, wielu programistów i organizacji zaczęło go adoptować w swoich projektach. Możliwość rozszerzania i manipulowania DOM oferowaną przez bibliotekę jest świetna, a ponadto mamy wiele wtyczek do dodawania zachowań do naszych stron w przypadku konieczności wykonywania zadań, które nie są obsługiwane przez główną bibliotekę jQuery. Uprościło to wiele pracy programistom iw tym momencie uczyniło JavaScript potężnym językiem do tworzenia aplikacji internetowych lub aplikacji jednostronicowych.

Wynik popularności jQuery jest mierzalny do dziś: prawie 80% najpopularniejszych serwisów na świecie nadal z niego korzysta. Oto niektóre z powodów, dla których jQuery jest tak popularne:

  • Obsługuje manipulacje DOM.
  • Zapewnia manipulację CSS.
  • Działa tak samo we wszystkich przeglądarkach internetowych.
  • Zawiera metody zdarzeń HTML.
  • Łatwe tworzenie połączeń AJAX.
  • Łatwe w użyciu efekty i animacje.

Przez lata JavaScript bardzo się zmienił i dodał kilka funkcji, których nie mieliśmy w przeszłości. Wraz z przedefiniowaniem i ewolucją ECMAScript, niektóre z funkcji dostarczanych przez jQuery zostały dodane do standardowych funkcji JavaScript i obsługiwane przez wszystkie przeglądarki internetowe. W związku z tym niektóre zachowania oferowane przez jQuery nie były już potrzebne , ponieważ jesteśmy w stanie zrobić to samo za pomocą zwykłego JavaScript.

Z drugiej strony zaczął się pojawiać nowy sposób myślenia i projektowania interfejsów użytkownika. Frameworki takie jak React, Angular czy Vue pozwalają programistom tworzyć aplikacje internetowe oparte na komponentach funkcjonalnych wielokrotnego użytku. React, tzn. współpracuje z „wirtualnym DOM”, który jest reprezentacją DOM w pamięci, podczas gdy jQuery współdziała bezpośrednio z DOM w mniej wydajny sposób. Ponadto React oferuje fajne funkcje ułatwiające rozwój niektórych funkcji, takich jak zarządzanie stanem. Dzięki temu nowemu podejściu i popularności, jaką zaczęły zdobywać aplikacje jednostronicowe, wielu programistów zaczęło używać Reacta w swoich projektach aplikacji internetowych.

Rozwój front-endu ewoluował jeszcze bardziej, dzięki frameworkom stworzonym na bazie innych frameworków. Tak jest na przykład w przypadku Next.js. Jak zapewne wiesz, jest to framework React o otwartym kodzie źródłowym, który oferuje funkcje generowania stron statycznych, tworzenia stron renderowanych po stronie serwera i łączenia obu typów w tej samej aplikacji. Umożliwia także tworzenie bezserwerowych interfejsów API w tej samej aplikacji.

Istnieje ciekawy scenariusz: chociaż te frameworki frontendowe są z biegiem lat coraz bardziej popularne, jQuery jest nadal stosowane przez zdecydowaną większość stron internetowych. Jednym z powodów, dla których tak się dzieje, jest to, że odsetek stron internetowych korzystających z WordPressa jest naprawdę wysoki, a jQuery jest zawarte w CMS . Innym powodem jest to, że niektóre biblioteki, takie jak Bootstrap, są zależne od jQuery i istnieje kilka gotowych do użycia szablonów, które go używają i jego wtyczek.

Ale innym powodem tak dużej liczby witryn korzystających z jQuery jest koszt migracji kompletnej aplikacji internetowej do nowego frameworka. Nie jest to łatwe, nie jest tanie i czasochłonne. Ale ostatecznie praca z nowymi narzędziami i technologiami przynosi wiele korzyści: szersze wsparcie, pomoc społeczności, lepsze doświadczenie programistów i łatwość nakłonienia ludzi do pracy nad projektem.

Istnieje wiele scenariuszy, w których nie musimy (lub nie chcemy) podążać za architekturą, którą narzucają nam frameworki, takie jak React lub Next.js, i to jest w porządku. Jednak jQuery to biblioteka zawierająca dużo kodu i funkcji, które nie są już potrzebne. Wiele funkcji oferowanych przez jQuery można uzyskać za pomocą nowoczesnych natywnych funkcji JavaScript i prawdopodobnie w bardziej wydajny sposób.

Porozmawiajmy o tym, jak moglibyśmy przestać używać jQuery i przenieść naszą stronę do aplikacji webowej React lub Next.js.

Zdefiniuj strategię migracji

Czy potrzebujemy biblioteki?

W zależności od funkcji naszej aplikacji internetowej możemy nawet mieć przypadek, w którym framework nie jest tak naprawdę potrzebny. Jak wspomniano wcześniej, kilka funkcji jQuery zostało włączonych (lub przynajmniej bardzo podobna) do najnowszych wersji standardu internetowego. Tak więc, biorąc pod uwagę, że:

  • Wzorzec $(selector) z jQuery można zastąpić querySelectorAll() .

Zamiast robić:

 $("#someId");

Możemy zrobić:

 document.querySelectorAll("#someId");
  • Mamy teraz właściwość Element.classList , jeśli chcemy manipulować klasami CSS.

Zamiast robić:

 $(selector).addClass(className);

Możemy zrobić:

 element.classList.add(className);
  • Wiele animacji można wykonać bezpośrednio za pomocą CSS, zamiast implementować JavaScript.

Zamiast robić:

 $(selector).fadeIn();

Możemy zrobić:

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

I zastosuj trochę stylów CSS:

 .show { transition: opacity 400ms; } .hide { opacity: 0; }
  • Mamy teraz funkcję addEventListener, jeśli chcemy obsługiwać zdarzenia.

Zamiast robić:

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

Możemy zrobić:

 element.addEventListener(eventName, eventHandler);
  • Zamiast używać jQuery Ajax, możemy użyć XMLHttpRequest .

Zamiast robić:

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

Możemy zrobić:

 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);

Aby uzyskać więcej informacji, możesz zapoznać się z tymi fragmentami kodu JavaScript waniliowego.

Zidentyfikuj komponenty

Jeśli używamy jQuery w naszej aplikacji, powinniśmy mieć trochę treści HTML, która jest generowana na serwerze WWW oraz kod JavaScript, który dodaje interaktywność do strony. Prawdopodobnie dodajemy obsługę zdarzeń podczas ładowania strony, która będzie manipulować DOM, gdy wystąpią zdarzenia, prawdopodobnie aktualizując CSS lub styl elementów. Możemy również wywoływać usługi backendu w celu wykonania działań, które mogą wpłynąć na DOM strony, a nawet ją przeładować.

Pomysł polegałby na refaktoryzacji kodu JavaScript znajdującego się na stronach i zbudowaniu komponentów React. Pomoże nam to połączyć powiązany kod i skomponować elementy, które będą częścią większej kompozycji. Dzięki temu będziemy mogli również lepiej obsługiwać stan naszej aplikacji. Analizując frontend naszej aplikacji, powinniśmy podzielić go na części dedykowane do konkretnego zadania, abyśmy mogli na jego podstawie tworzyć komponenty.

Jeśli mamy przycisk:

 <button>Click</button>

Z następującą logiką:

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

Możemy go przenieść do komponentu React:

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

Powinniśmy jednak również ocenić, jak zakończy się proces migracji, ponieważ nasza aplikacja działa i jest używana, a nie chcemy na nią wpływać (a przynajmniej w jak najmniejszym stopniu).

Dobra migracja

Dobra migracja to taka, w której wszystkie części aplikacji są w pełni migrowane do nowej platformy lub technologii. Byłby to idealny scenariusz dla naszej aplikacji, ponieważ synchronizowalibyśmy wszystkie części i korzystalibyśmy z ujednoliconego narzędzia i unikalnej wersji, do której się odnosimy.

Dobra i kompletna migracja zazwyczaj obejmuje całkowite przepisanie kodu naszej aplikacji i to ma sens. Jeśli budujemy aplikację od podstaw, mamy możliwość decydowania, w jakim kierunku chcemy podążać z nowym kodem. Moglibyśmy wykorzystać nowy punkt widzenia na nasze istniejące systemy i przepływ pracy i stworzyć zupełnie nową aplikację z wiedzą, którą mamy w tej chwili, bardziej kompletną niż ta, którą mieliśmy, kiedy tworzyliśmy naszą aplikację internetową.

Ale całkowite przepisanie ma pewne problemy. Przede wszystkim wymaga dużo czasu. Im większa aplikacja, tym więcej czasu będziemy potrzebowali na jej przepisanie. Kolejnym problemem jest ilość pracy i ilość programistów, których to wymaga. A jeśli nie przeprowadzamy migracji progresywnej, musimy pomyśleć o tym, jak długo nasza aplikacja będzie niedostępna.

Normalnie, całkowite przepisanie może być wykonane w przypadku małych projektów, projektów, które nie zmieniają się często lub aplikacji, które nie są tak krytyczne dla naszej działalności.

Szybka migracja

Innym podejściem jest podzielenie aplikacji na części lub części. Przeprowadzamy migrację aplikacji część po części i udostępniamy te części, gdy są gotowe. Dlatego przenieśliśmy części naszej aplikacji dostępne dla użytkowników i współistniejące z naszą istniejącą aplikacją produkcyjną.

Dzięki tej stopniowej migracji dostarczamy użytkownikom oddzielne funkcje naszego projektu w szybszy sposób, ponieważ nie musimy czekać na przepisanie całej aplikacji. Otrzymujemy również szybsze informacje zwrotne od użytkowników, co pozwala nam wcześniej wykrywać błędy lub problemy.

Ale stopniowa migracja zmusza nas do posiadania różnych narzędzi, bibliotek, zależności i frameworków. Albo możemy nawet obsługiwać różne wersje tego samego narzędzia. To rozszerzone wsparcie może powodować konflikty w naszej aplikacji.

Moglibyśmy nawet mieć problemy, jeśli zastosujemy zasady w zakresie globalnym, ponieważ każda z migrowanych części może działać w inny sposób, ale podlega wpływowi kodu, który ustawia parametry globalne w naszym systemie. Przykładem tego jest użycie logiki kaskadowej do stylizacji CSS.

Wyobraź sobie, że pracujemy z różnymi wersjami jQuery w naszej aplikacji internetowej, ponieważ dodaliśmy funkcjonalności z nowszych wersji do modułów, które zostały utworzone później. Jak skomplikowana byłaby migracja całej naszej aplikacji do nowszej wersji jQuery? Teraz wyobraź sobie ten sam scenariusz, ale migrację do zupełnie innego frameworka, takiego jak Next.js. To może być skomplikowane.

Migracja Frankensteina

Denys Mishunov napisał artykuł w Smashing Magazine, przedstawiając alternatywę dla tych dwóch pomysłów na migrację, próbując wykorzystać to, co najlepsze z dwóch poprzednich podejść: Migracja Frankensteina. Opiera proces migracji na dwóch głównych komponentach: mikroserwisach i komponentach internetowych.

Proces migracji składa się z listy kroków, które należy wykonać:

1. Zidentyfikuj mikroserwisy

Bazując na naszym kodzie aplikacji, powinniśmy podzielić go na niezależne części, które są dedykowane jednej małej pracy. Jeśli myślimy o użyciu React lub Next.js, możemy połączyć koncepcję mikroserwisów z różnymi komponentami, które posiadamy.

Pomyślmy o aplikacji listy zakupów jako przykładu. Mamy listę rzeczy do kupienia i możliwość dodania kolejnych rzeczy do listy. Jeśli więc chcemy podzielić naszą aplikację na małe części, możemy pomyśleć o komponencie „lista elementów” i „dodaj element”. W ten sposób możemy rozdzielić funkcjonalność i znaczniki związane z każdą z tych części na różne komponenty React.

Aby potwierdzić, że komponenty są niezależne, powinniśmy być w stanie usunąć jeden z nich z aplikacji, a pozostałe nie powinny mieć wpływu. Jeśli otrzymamy błąd podczas usuwania znaczników i funkcjonalności z usługi, oznacza to, że nie identyfikujemy poprawnie składników lub musimy zrefaktoryzować sposób działania naszego kodu.

2. Zezwól na dostęp z hosta do obcego

„Host” to nasza istniejąca aplikacja. „Obcy” to ten, który zaczniemy tworzyć z nowym frameworkiem. Oba powinny działać niezależnie, ale powinniśmy zapewnić dostęp od Hosta do Obcego. Powinniśmy być w stanie wdrożyć dowolną z dwóch aplikacji bez przerywania drugiej, ale zachowując komunikację między nimi.

3. Napisz obcy komponent

Przepisz usługę z naszej aplikacji Host do naszej aplikacji Alien, korzystając z nowego frameworka. Komponent powinien kierować się tą samą zasadą niezależności, o której wspomnieliśmy wcześniej.

Wróćmy do przykładu z listą zakupów. Zidentyfikowaliśmy składnik „dodaj element”. W jQuery znaczniki komponentu będą wyglądać mniej więcej tak:

 <input class="new-item" />

A kod JavaScript/jQuery do dodania pozycji do listy będzie wyglądał mniej więcej tak:

 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(''); });

Zamiast tego możemy stworzyć komponent 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. Napisz opakowanie komponentów sieci Web wokół usługi obcych

Utwórz komponent opakowujący, który importuje naszą właśnie utworzoną usługę Alien i renderuje ją. Pomysł polega na stworzeniu pomostu między aplikacją Host a aplikacją Alien. Należy pamiętać, że do wygenerowania kodu JavaScript, który działa w naszej obecnej aplikacji, może być nam potrzebny pakiet pakunków, ponieważ będziemy musieli skopiować nasze nowe komponenty React i sprawić, by działały.

Idąc za przykładem listy zakupów, możemy utworzyć plik AddItem-wrapper.js w projekcie Host. Ten plik będzie zawierał kod, który otacza nasz już utworzony komponent AddItem i tworzy z nim niestandardowy element:

 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);

Powinniśmy przynieść niezbędne moduły węzłów i komponenty z folderów aplikacji Alien, ponieważ musimy je zaimportować, aby komponent działał.

5. Zastąp usługę hosta komponentem sieciowym

Ten składnik opakowujący zastąpi ten w aplikacji Host i zaczniemy go używać. Tak więc aplikacja w produkcji będzie mieszanką komponentów Hosta i komponentów owiniętych przez Alien.

W naszej przykładowej aplikacji Host powinniśmy zamienić:

 <input class="new-item" />

Z

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

6. Opłucz i powtórz

Wykonaj kroki 3, 4 i 5 dla każdej ze zidentyfikowanych mikrousług.

7. Przełącz się na obcego

Host jest teraz zbiorem komponentów opakowujących, które zawierają wszystkie komponenty sieciowe, które stworzyliśmy w aplikacji Alien. Ponieważ przekonwertowaliśmy wszystkie zidentyfikowane mikroserwisy, możemy powiedzieć, że aplikacja Alien została zakończona i wszystkie usługi zostały zmigrowane. Musimy tylko teraz skierować naszych użytkowników do aplikacji Alien.

Metoda migracji Frankensteina działa jako połączenie podejścia Dobrego i Szybkiego. Przeprowadzamy migrację całej aplikacji, ale po jej zakończeniu udostępniamy różne komponenty. Dzięki temu są dostępne do wcześniejszego wykorzystania i oceny przez użytkowników w produkcji.

Musimy jednak wziąć pod uwagę, że nad tym podejściem pracujemy nadmiernie. Jeśli chcemy używać komponentów, które tworzymy dla naszej aplikacji Alien, musimy utworzyć komponent opakowujący, który zostanie dołączony do aplikacji Host. To sprawia, że ​​spędzamy czas na rozwijaniu kodu dla tych elementów opakowujących. Ponadto, używając ich w naszej aplikacji Host, powielamy włączenie kodu i zależności oraz dodajemy kod, który wpłynie na wydajność naszej aplikacji.

Aplikacja Dusiciela

Innym podejściem, które możemy zastosować, jest Strangulation Legacy Application. Identyfikujemy krawędzie naszej istniejącej aplikacji internetowej i za każdym razem, gdy potrzebujemy dodać funkcjonalności do naszej aplikacji, robimy to za pomocą nowszego frameworka, dopóki stary system nie zostanie „uduszony”. Takie podejście pomaga nam zmniejszyć potencjalne ryzyko, które możemy eksperymentować podczas migracji aplikacji.

Aby zastosować to podejście, musimy zidentyfikować różne komponenty, tak jak robimy to w przypadku Frankenstein Migration. Po podzieleniu naszej aplikacji na różne fragmenty powiązanego kodu imperatywnego umieszczamy je w nowych komponentach React. Nie dodajemy żadnych dodatkowych zachowań, po prostu tworzymy komponenty React, które renderują naszą istniejącą zawartość.

Zobaczmy przykład, aby uzyskać więcej wyjaśnień. Załóżmy, że w naszej aplikacji mamy następujący kod HTML:

 <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 ten kod JavaScript (zamieniliśmy już funkcje jQuery na nowe standardowe funkcje 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'); }); } }

Jest to powszechna implementacja komponentu accordion dla JavaScript. Ponieważ chcemy wprowadzić tutaj React, musimy otoczyć nasz istniejący kod nowym komponentem 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"))

Komponent nie dodaje żadnego nowego zachowania ani funkcji. Używamy useEffect , ponieważ komponent został zamontowany w dokumencie. Dlatego funkcja zwraca null, ponieważ hook nie musi zwracać komponentu.

Nie dodaliśmy więc żadnych nowych funkcji do naszej istniejącej aplikacji, ale wprowadziliśmy Reacta bez zmiany jego zachowania. Od teraz za każdym razem, gdy dodamy nowe funkcje lub zmiany w naszym kodzie, będziemy to robić przy użyciu nowszego wybranego frameworka.

Renderowanie po stronie klienta, renderowanie po stronie serwera czy generacja statyczna?

Next.js daje nam możliwość wyboru sposobu renderowania każdej strony naszej aplikacji internetowej. Możemy wykorzystać renderowanie po stronie klienta, które już oferuje nam React, do generowania treści bezpośrednio w przeglądarce użytkownika. Lub możemy renderować zawartość naszej strony na serwerze za pomocą renderowania po stronie serwera. Wreszcie, możemy stworzyć zawartość naszej strony w czasie budowania za pomocą generowania statycznego.

W naszej aplikacji powinniśmy ładować i renderować kod podczas ładowania strony, zanim zaczniemy wchodzić w interakcje z jakąkolwiek biblioteką lub frameworkiem JavaScript. Możemy używać języka programowania lub technologii renderowania po stronie serwera, takiego jak ASP.NET, PHP lub Node.js. Możemy skorzystać z funkcji Next.js i zastąpić naszą obecną metodę renderowania metodą renderowania po stronie serwera Next.js . W ten sposób zachowujemy wszystkie zachowania w tym samym projekcie, który działa pod parasolem wybranego przez nas frameworka. Ponadto utrzymujemy logikę naszej strony głównej i komponentów React w tym samym kodzie, który generuje wszystkie potrzebne treści dla naszej strony.

Pomyślmy o stronie dashboardu jako przykładzie. Możemy wygenerować wszystkie początkowe znaczniki strony w czasie ładowania na serwerze, zamiast generować je za pomocą React w przeglądarce internetowej użytkownika.

 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

Jeśli znacznik, który renderujemy podczas ładowania strony, jest przewidywalny i opiera się na danych, które możemy pobrać w czasie kompilacji, dobrym wyborem będzie generowanie statyczne. Generowanie statycznych zasobów w czasie kompilacji sprawi, że nasza aplikacja będzie szybsza, bezpieczniejsza, skalowalna i łatwiejsza w utrzymaniu. A jeśli musimy generować dynamiczną zawartość na stronach naszej aplikacji, możemy użyć renderowania po stronie klienta Reacta, aby pobrać informacje z usług lub źródeł danych.

Wyobraź sobie, że mamy witrynę z blogiem, na której znajduje się wiele wpisów na blogu. Jeśli użyjemy generowania statycznego, możemy utworzyć ogólny plik [blog-slug].js w naszej aplikacji Next.js, a dodając następujący kod, wygenerujemy wszystkie strony statyczne dla naszych postów na blogu w czasie kompilacji.

 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)), }, } }

Utwórz interfejs API za pomocą tras API

Jedną ze wspaniałych funkcji oferowanych przez Next.js jest możliwość tworzenia tras API. Dzięki nim możemy tworzyć własne funkcje bezserwerowe za pomocą Node.js. Możemy również zainstalować pakiety NPM w celu rozszerzenia funkcjonalności. Fajną rzeczą w tym jest to, że nasz interfejs API zostanie pozostawiony w tym samym projekcie/aplikacji, co nasz frontend, więc nie będziemy mieć żadnych problemów z CORS.

Jeśli utrzymamy API, które jest wywoływane z naszej aplikacji internetowej za pomocą funkcjonalności jQuery AJAX, możemy je zastąpić za pomocą API Routes . W ten sposób zachowamy całą bazę kodu naszej aplikacji w tym samym repozytorium i uprościmy wdrożenie naszej aplikacji. Jeśli korzystamy z usługi innej firmy, możemy użyć Tras API do „maskowania” zewnętrznych adresów URL.

Moglibyśmy mieć API Route /pages/api/get/[id].js , które zwraca dane, których używamy na naszej stronie.

 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 zadzwoń z kodu naszej strony.

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

Wdróż w Netlify

Netlify to kompletna platforma, której można używać do automatyzacji, zarządzania, budowania, testowania, wdrażania i hostowania aplikacji internetowych. Posiada wiele funkcji, które ułatwiają i przyspieszają tworzenie nowoczesnych aplikacji internetowych. Niektóre najważniejsze informacje Netlify to:

  • Globalna platforma hostingowa CDN,
  • obsługa funkcji bezserwerowych,
  • Wdrażaj podglądy w oparciu o Github Pull Request,
  • Webhooki,
  • Natychmiastowe wycofywanie,
  • Kontrola dostępu oparta na rolach.

Netlify to świetna platforma do zarządzania i hostowania naszych aplikacji Next.js, a wdrożenie aplikacji internetowej za jej pomocą jest dość proste.

Przede wszystkim musimy śledzić nasz kod aplikacji Next.js w repozytorium Git. Netlify łączy się z GitHub (lub preferowaną przez nas platformą Git) i za każdym razem, gdy w gałęzi zostanie wprowadzona zmiana (zatwierdzenie lub pull request), zostanie uruchomione automatyczne zadanie „buduj i wdrażaj”.

Kiedy już mamy repozytorium Git z kodem naszej aplikacji, musimy stworzyć dla niego „Stroną Netlify”. Aby to zrobić, mamy dwie opcje:

  1. Korzystanie z Netlify CLI
    Po zainstalowaniu CLI ( npm install -g netlify-cli ) i zalogowaniu się na nasze konto Netlify ( ntl login ), możemy przejść do katalogu głównego naszej aplikacji, uruchomić ntl init i postępować zgodnie z instrukcjami.
  2. Korzystanie z aplikacji internetowej Netlify
    Powinniśmy przejść do https://app.netlify.com/start. Połącz się z naszym dostawcą Git, wybierz repozytorium naszej aplikacji z listy, skonfiguruj niektóre opcje kompilacji i wdróż.

W przypadku obu metod musimy wziąć pod uwagę, że nasze polecenie build będzie next build , a nasz katalog do wdrożenia jest out .

Wreszcie wtyczka Essential Next.js jest instalowana automatycznie, co pozwoli nam wdrożyć i używać tras API, tras dynamicznych i trybu podglądu. I to wszystko, mamy naszą aplikację Next.js działającą w szybkiej i stabilnej usłudze hostingowej CDN.

Wniosek

W tym artykule oceniliśmy strony internetowe za pomocą biblioteki jQuery i porównaliśmy je z nowymi frameworkami frontendowymi, takimi jak React i Next.js. Określiliśmy, w jaki sposób możemy rozpocząć migrację do nowszego narzędzia, jeśli nam to przyniesie korzyści. Oceniliśmy różne strategie migracji i zobaczyliśmy kilka przykładów scenariuszy, które moglibyśmy przenieść do projektów aplikacji webowych Next.js. Na koniec zobaczyliśmy, jak wdrożyć naszą aplikację Next.js w Netlify i uruchomić ją.

Dalsza lektura i zasoby

  • Migracja Frankensteina: podejście niezależne od frameworka
  • Usuwanie jQuery z frontendu GitHub.com
  • Pierwsze kroki z Next.js
  • Jak wdrożyć witryny Next.js w Netlify
  • Artykuły Next.js w Netlify Blog