Comment migrer de jQuery vers Next.js

Publié: 2022-03-10
Résumé rapide ↬ Dans cet article, nous examinons de plus près différentes approches et stratégies sur la façon dont nous pouvons migrer une application Web qui utilise le framework jQuery, et commencer à utiliser l'un des frameworks React les plus cool du marché : Next.js.

Lorsque jQuery est apparu en 2006, de nombreux développeurs et organisations ont commencé à l'adopter pour leurs projets. La possibilité d' étendre et de manipuler le DOM qu'offre la bibliothèque est excellente, et nous avons également de nombreux plugins pour ajouter un comportement à nos pages au cas où nous aurions besoin d'effectuer des tâches qui ne sont pas prises en charge par la bibliothèque principale jQuery. Cela a simplifié une grande partie du travail des développeurs et, à ce moment-là, cela a fait de JavaScript un langage puissant pour créer des applications Web ou des applications à page unique.

Le résultat de la popularité de jQuery est encore mesurable aujourd'hui : près de 80% des sites Web les plus populaires du monde l'utilisent encore. Certaines des raisons pour lesquelles jQuery est si populaire sont :

  • Il prend en charge la manipulation DOM.
  • Il fournit une manipulation CSS.
  • Fonctionne de la même manière sur tous les navigateurs Web.
  • Il encapsule les méthodes d'événement HTML.
  • Création facile d'appels AJAX.
  • Effets et animations faciles à utiliser.

Au fil des ans, JavaScript a beaucoup changé et a ajouté plusieurs fonctionnalités que nous n'avions pas auparavant. Avec la redéfinition et l'évolution d'ECMAScript, certaines des fonctionnalités fournies par jQuery ont été ajoutées aux fonctionnalités JavaScript standard et prises en charge par tous les navigateurs Web. Avec cela, certains des comportements proposés par jQuery n'étaient plus nécessaires , car nous sommes capables de faire les mêmes choses avec du JavaScript simple.

D'autre part, une nouvelle façon de penser et de concevoir des interfaces utilisateur a commencé à émerger. Des frameworks comme React, Angular ou Vue permettent aux développeurs de créer des applications web basées sur des composants fonctionnels réutilisables. React, c'est-à-dire fonctionne avec le « DOM virtuel », qui est une représentation du DOM en mémoire, alors que jQuery interagit directement avec le DOM , de manière moins performante. De plus, React propose des fonctionnalités intéressantes pour faciliter le développement de certaines fonctionnalités, telles que la gestion des états. Avec cette nouvelle approche et la popularité que les applications à page unique ont commencé à gagner, de nombreux développeurs ont commencé à utiliser React pour leurs projets d'applications Web.

Et le développement frontal a encore évolué, avec des frameworks créés au-dessus d'autres frameworks. C'est le cas par exemple de Next.js. Comme vous le savez probablement, il s'agit d'un framework React open source qui offre des fonctionnalités pour générer des pages statiques, créer des pages rendues côté serveur et combiner les deux types dans la même application. Il permet également de créer des API sans serveur dans la même application.

Il y a un scénario curieux : même si ces frameworks frontaux sont de plus en plus populaires au fil des années, jQuery est toujours adopté par une grande majorité de pages Web. L'une des raisons pour lesquelles cela se produit est que le pourcentage de sites Web utilisant WordPress est très élevé et que jQuery est inclus dans le CMS . Une autre raison est que certaines bibliothèques, comme Bootstrap, dépendent de jQuery, et il existe des modèles prêts à l'emploi qui l'utilisent ainsi que ses plugins.

Mais une autre raison de ce nombre de sites Web utilisant jQuery est le coût de la migration d'une application Web complète vers un nouveau framework. Ce n'est pas facile, ce n'est pas bon marché et cela prend du temps. Mais, au final, travailler avec de nouveaux outils et technologies apporte de nombreux avantages : un support plus large, une assistance communautaire, une meilleure expérience de développement et une facilité à faire travailler les gens sur le projet.

Il existe de nombreux scénarios où nous n'avons pas besoin (ou ne voulons pas) de suivre l'architecture que des frameworks comme React ou Next.js nous imposent, et c'est OK. Cependant, jQuery est une bibliothèque qui contient beaucoup de code et de fonctionnalités qui ne sont plus nécessaires. De nombreuses fonctionnalités proposées par jQuery peuvent être réalisées à l'aide de fonctions natives JavaScript modernes , et probablement de manière plus performante.

Voyons comment nous pourrions arrêter d'utiliser jQuery et migrer notre site Web vers une application Web React ou Next.js.

Définir la stratégie de migration

Avons-nous besoin d'une bibliothèque ?

Selon les fonctionnalités de notre application web, nous pourrions même avoir le cas où un framework n'est pas vraiment nécessaire. Comme mentionné précédemment, plusieurs fonctionnalités de jQuery ont été incluses (ou du moins une très similaire) dans les dernières versions des standards Web. Donc, considérant que :

  • Le motif $(selector) de jQuery peut être remplacé par querySelectorAll() .

Au lieu de faire :

 $("#someId");

Nous pouvons faire:

 document.querySelectorAll("#someId");
  • Nous avons maintenant la propriété Element.classList si nous voulons manipuler des classes CSS.

Au lieu de faire :

 $(selector).addClass(className);

Nous pouvons faire:

 element.classList.add(className);
  • De nombreuses animations peuvent être réalisées directement à l'aide de CSS, au lieu d'implémenter JavaScript.

Au lieu de faire :

 $(selector).fadeIn();

Nous pouvons faire:

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

Et appliquez un style CSS :

 .show { transition: opacity 400ms; } .hide { opacity: 0; }
  • Nous avons maintenant la fonction addEventListener si nous voulons gérer les événements.

Au lieu de faire :

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

Nous pouvons faire:

 element.addEventListener(eventName, eventHandler);
  • Au lieu d'utiliser jQuery Ajax, nous pouvons utiliser XMLHttpRequest .

Au lieu de faire :

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

Nous pouvons faire:

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

Pour plus de détails, vous pouvez consulter ces extraits de code JavaScript Vanilla.

Identifier les composants

Si nous utilisons jQuery dans notre application, nous devrions avoir du contenu HTML généré sur le serveur Web et du code JavaScript qui ajoute de l'interactivité à la page. Nous ajoutons probablement des gestionnaires d'événements au chargement de la page qui manipuleront le DOM lorsque les événements se produiront, mettant probablement à jour le CSS ou le style des éléments. Nous pourrions également appeler des services backend pour exécuter des actions, qui peuvent affecter le DOM de la page, ou même la recharger.

L'idée serait de refactoriser le code JavaScript vivant dans les pages et de construire des composants React. Cela nous aidera à joindre le code associé et à composer des éléments qui feront partie d'une composition plus large. Ce faisant, nous pourrons également mieux gérer l'état de notre application. En analysant le frontend de notre application, nous devons le diviser en parties dédiées à une certaine tâche, afin que nous puissions créer des composants basés sur cela.

Si nous avons un bouton :

 <button>Click</button>

Avec la logique suivante :

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

Nous pouvons le migrer vers un composant React :

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

Mais nous devons également évaluer comment le processus de migration sera accompli puisque notre application fonctionne et est utilisée, et nous ne voulons pas l'affecter (ou, du moins, l'affecter le moins possible).

Bonne migration

Une bonne migration est celle où toutes les parties de l'application sont entièrement migrées vers le nouveau framework ou la nouvelle technologie. Ce serait le scénario idéal pour notre application puisque nous synchroniserions toutes les parties, et nous utiliserions un outil unifié et une version référencée unique.

Une bonne et complète migration comprend généralement une réécriture complète du code de notre application, et cela a du sens. Si nous construisons une application à partir de zéro, nous avons la possibilité de décider quelle direction nous voulons prendre avec le nouveau code. Nous pourrions utiliser un nouveau point de vue sur nos systèmes et flux de travail existants, et créer une toute nouvelle application avec les connaissances que nous avons en ce moment, plus complète que celle que nous avions lorsque nous avons créé notre application Web pour la première fois.

Mais une réécriture complète a quelques problèmes. Tout d'abord, cela demande beaucoup de temps. Plus l'application est grosse, plus nous aurons besoin de temps pour la réécrire. Un autre problème est la quantité de travail et le nombre de développeurs nécessaires. Et, si nous ne procédons pas à une migration progressive, nous devons penser à la durée d'indisponibilité de notre application.

Normalement, une réécriture complète peut être réalisée avec de petits projets, des projets qui ne changent pas fréquemment ou des applications qui ne sont pas si critiques pour notre entreprise.

Migration rapide

Une autre approche consiste à diviser l'application en parties ou en morceaux. Nous migrons l'application partie par partie et nous publions ces parties lorsqu'elles sont prêtes. Nous avons donc migré des parties de notre application disponibles pour les utilisateurs et coexistant avec notre application de production existante.

Avec cette migration progressive, nous livrons plus rapidement aux utilisateurs des fonctionnalités séparées de notre projet, car nous n'avons pas à attendre que l'application complète soit réécrite. Nous obtenons également des retours plus rapides des utilisateurs, ce qui nous permet de détecter plus tôt les bogues ou les problèmes.

Mais une migration progressive nous pousse à avoir des outils, des bibliothèques, des dépendances et des frameworks différents. Ou nous pourrions même avoir à prendre en charge différentes versions du même outil. Cette prise en charge étendue pourrait entraîner des conflits dans notre application.

Nous pourrions même avoir des problèmes si nous appliquons des politiques dans la portée globale puisque chacune des parties migrées pourrait fonctionner d'une manière différente, mais être affectée par le code qui définit les paramètres globaux de notre système. Un exemple de ceci est l'utilisation d'une logique en cascade pour le style CSS.

Imaginez que nous travaillions avec différentes versions de jQuery dans notre application Web, car nous avons ajouté des fonctionnalités de versions plus récentes aux modules qui ont été créés ultérieurement. Serait-il compliqué de migrer toutes nos applications vers une version plus récente de jQuery ? Maintenant, imaginez le même scénario mais en migrant vers un framework complètement différent comme Next.js. Cela peut être compliqué.

Migration de Frankenstein

Denys Mishunov a écrit un article sur Smashing Magazine présentant une alternative à ces deux idées de migration, essayant d'obtenir le meilleur des deux approches précédentes : la migration Frankenstein. Il base le processus de migration sur deux composants principaux : les microservices et les composants Web.

Le processus de migration consiste en une liste d'étapes à suivre :

1. Identifier les microservices

Sur la base de notre code d'application, nous devrions le diviser en parties indépendantes dédiées à un petit travail. Si nous envisageons d'utiliser React ou Next.js, nous pourrions lier le concept de microservices aux différents composants dont nous disposons.

Prenons l'exemple d'une application de liste de courses. Nous avons une liste de choses à acheter et une entrée pour ajouter plus de choses à la liste. Donc, si nous voulons diviser notre application en petites parties, nous pourrions penser à un composant « liste d'éléments » et à un composant « ajouter un élément ». Ce faisant, nous pouvons séparer les fonctionnalités et le balisage liés à chacune de ces parties en différents composants React.

Pour corroborer que les composants sont indépendants, nous devrions pouvoir supprimer l'un d'eux de l'application, et les autres ne devraient pas être affectés par cela. Si nous obtenons une erreur lors de la suppression du balisage et des fonctionnalités d'un service, nous n'identifions pas correctement les composants, ou nous devons refactoriser le fonctionnement de notre code.

2. Autoriser l'accès hôte à extraterrestre

"Hôte" est notre application existante. "Alien" est celui que nous allons commencer à créer, avec le nouveau framework. Les deux doivent fonctionner indépendamment, mais nous devons fournir un accès de Host à Alien. Nous devrions être en mesure de déployer l'une des deux applications sans casser l'autre, mais en gardant la communication entre elles.

3. Écrire un composant extraterrestre

Réécrivez un service de notre application Host dans notre application Alien, en utilisant le nouveau framework. Le composant doit suivre le même principe d'indépendance que nous avons mentionné précédemment.

Revenons à l'exemple de la liste d'épicerie. Nous avons identifié un composant "ajouter un élément". Avec jQuery, le balisage du composant ressemblera à ceci :

 <input class="new-item" />

Et le code JavaScript/jQuery pour ajouter les éléments à la liste ressemblera à ceci :

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

Au lieu de cela, nous pouvons créer un composant 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. Écrire un wrapper de composant Web autour d'un service extraterrestre

Créez un composant wrapper qui importe notre service Alien que vous venez de créer et le restitue. L'idée est de créer un pont entre l'application Host et l'application Alien. Gardez à l'esprit que nous pourrions avoir besoin d'un package bundler pour générer du code JavaScript qui fonctionne dans notre application actuelle, car nous devrons copier nos nouveaux composants React et les faire fonctionner.

En suivant l'exemple de la liste de courses, nous pouvons créer un fichier AddItem-wrapper.js dans le projet Host. Ce fichier contiendra le code qui encapsule notre composant AddItem déjà créé et crée un élément personnalisé avec :

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

Nous devons apporter les modules et composants de nœud nécessaires à partir des dossiers de l'application Alien, car nous devons les importer pour que le composant fonctionne.

5. Remplacer le service hôte par un composant Web

Ce composant wrapper remplacera celui de l'application Host et nous commencerons à l'utiliser. Ainsi, l'application en production sera un mélange de composants Host et de composants enveloppés Alien.

Dans notre exemple d'application Host, nous devons remplacer :

 <input class="new-item" />

Avec

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

6. Rincer et répéter

Suivez les étapes 3, 4 et 5 pour chacun des microservices identifiés.

7. Passez à l'extraterrestre

Host est maintenant une collection de composants wrapper qui incluent tous les composants Web que nous avons créés sur l'application Alien. Comme nous avons converti tous les microservices identifiés, nous pouvons dire que l'application Alien est terminée et que tous les services ont été migrés. Nous avons juste besoin de pointer nos utilisateurs vers l'application Alien maintenant.

La méthode Frankenstein Migration fonctionne comme une combinaison des approches Good et Fast. Nous migrons l'application complète mais publions les différents composants lorsqu'ils sont terminés. Ainsi, ils sont disponibles pour être utilisés plus tôt et évalués par les utilisateurs en production.

Nous devons considérer, cependant, que nous faisons un peu plus de travail avec cette approche. Si nous voulons utiliser les composants que nous créons pour notre application Alien, nous devons créer un composant wrapper à inclure dans l'application Host. Cela nous fait passer du temps à développer le code de ces éléments wrapper. De plus, en les utilisant dans notre application hôte, nous dupliquons l'inclusion de code et de dépendances, et ajoutons du code qui affectera les performances de notre application.

Demande d'étrangleur

Une autre approche que nous pouvons adopter est l'étranglement des applications héritées. Nous identifions les limites de notre application Web existante, et chaque fois que nous avons besoin d'ajouter des fonctionnalités à notre application, nous le faisons en utilisant un cadre plus récent jusqu'à ce que l'ancien système soit « étranglé ». Cette approche nous aide à réduire le risque potentiel que nous pouvons expérimenter lors de la migration d'une application.

Pour suivre cette approche, nous devons identifier différents composants, comme nous le faisons dans Frankenstein Migration. Une fois que nous avons divisé notre application en différents morceaux de code impératif associés, nous les enveloppons dans de nouveaux composants React. Nous n'ajoutons aucun comportement supplémentaire, nous créons simplement des composants React qui restituent notre contenu existant.

Voyons un exemple pour plus de clarté. Supposons que nous ayons ce code HTML dans notre application :

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

Et ce code JavaScript (nous avons déjà remplacé les fonctions jQuery par de nouvelles fonctionnalités 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'); }); } }

Il s'agit d'une implémentation courante d'un composant accordion pour JavaScript. Comme nous voulons introduire React ici, nous devons envelopper notre code existant avec un nouveau composant 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"))

Le composant n'ajoute aucun nouveau comportement ou fonctionnalité. Nous utilisons useEffect car le composant a été monté dans le document. C'est pourquoi la fonction renvoie null car le hook n'a pas besoin de renvoyer un composant.

Nous n'avons donc ajouté aucune nouvelle fonctionnalité à notre application existante, mais nous avons introduit React sans modifier son comportement. À partir de maintenant, chaque fois que nous ajouterons de nouvelles fonctionnalités ou modifierons notre code, nous le ferons en utilisant le nouveau framework sélectionné.

Rendu côté client, rendu côté serveur ou génération statique ?

Next.js nous donne la possibilité de choisir comment nous voulons rendre chaque page de notre application web. Nous pouvons utiliser le rendu côté client que React nous propose déjà pour générer le contenu directement dans le navigateur de l'utilisateur. Ou, nous pouvons rendre le contenu de notre page sur le serveur en utilisant le rendu côté serveur. Enfin, nous pouvons créer le contenu de notre page au moment de la construction en utilisant la génération statique.

Dans notre application, nous devrions charger et rendre le code au chargement de la page, avant de commencer à interagir avec une bibliothèque ou un framework JavaScript. Nous utilisons peut-être un langage ou une technologie de programmation de rendu côté serveur, comme ASP.NET, PHP ou Node.js. Nous pouvons tirer parti des fonctionnalités de Next.js et remplacer notre méthode de rendu actuelle par la méthode de rendu côté serveur Next.js . Ce faisant, nous gardons tout le comportement à l'intérieur du même projet, qui fonctionne sous l'égide de notre framework sélectionné. De plus, nous gardons la logique de notre page principale et les composants React dans le même code qui génère tout le contenu nécessaire pour notre page.

Prenons l'exemple d'une page de tableau de bord. Nous pouvons générer tout le balisage initial de la page au moment du chargement, sur le serveur, au lieu de devoir le générer avec React dans le navigateur Web de l'utilisateur.

 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

Si le balisage que nous affichons au chargement de la page est prévisible et basé sur des données que nous pouvons récupérer au moment de la construction, la génération statique serait un bon choix. La génération d'actifs statiques au moment de la construction rendra notre application plus rapide, plus sécurisée, évolutive et plus facile à entretenir. Et, au cas où nous aurions besoin de générer du contenu dynamique sur les pages de notre application, nous pouvons utiliser le rendu côté client de React pour récupérer des informations à partir de services ou de sources de données.

Imaginez que nous ayons un site de blog, avec de nombreux articles de blog. Si nous utilisons la génération statique, nous pouvons créer un fichier générique [blog-slug].js dans notre application Next.js, et en ajoutant le code suivant, nous générerions toutes les pages statiques pour nos articles de blog au moment de la construction.

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

Créer une API à l'aide des routes d'API

L'une des grandes fonctionnalités offertes par Next.js est la possibilité de créer des API Routes. Avec eux, nous pouvons créer nos propres fonctions sans serveur en utilisant Node.js. Nous pouvons également installer des packages NPM pour étendre les fonctionnalités. Une chose intéressante à ce sujet est que notre API restera dans le même projet/application que notre interface, nous n'aurons donc aucun problème CORS.

Si nous maintenons une API appelée depuis notre application Web à l'aide de la fonctionnalité jQuery AJAX, nous pourrions les remplacer à l'aide d' API Routes . Ce faisant, nous conserverons toute la base de code de notre application dans le même référentiel, et nous simplifierons le déploiement de notre application. Si nous utilisons un service tiers, nous pouvons utiliser des API Routes pour « masquer » les URL externes.

Nous pourrions avoir une API Route /pages/api/get/[id].js qui renvoie les données que nous utilisons sur notre page.

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

Et appelez-le depuis le code de notre page.

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

Déployer sur Netlify

Netlify est une plate-forme complète qui peut être utilisée pour automatiser, gérer, créer, tester, déployer et héberger des applications Web. Il possède de nombreuses fonctionnalités qui facilitent et accélèrent le développement d'applications Web modernes. Certains points forts de Netlify sont :

  • Plateforme mondiale d'hébergement CDN,
  • Prise en charge des fonctions sans serveur,
  • Déployez des aperçus basés sur les demandes d'extraction Github,
  • Webhooks,
  • Annulations instantanées,
  • Contrôle d'accès basé sur les rôles.

Netlify est une excellente plate-forme pour gérer et héberger nos applications Next.js, et il est assez simple de déployer une application Web avec.

Tout d'abord, nous devons garder une trace de notre code d'application Next.js dans un référentiel Git. Netlify se connecte à GitHub (ou à la plateforme Git que nous préférons), et chaque fois qu'un changement est introduit dans une branche (un commit ou une Pull Request), une tâche automatique de "construction et déploiement" sera déclenchée.

Une fois que nous avons un référentiel Git avec le code de notre application, nous devons créer un « site Netlify » pour celui-ci. Pour ce faire, nous avons deux options :

  1. Utilisation de Netlify CLI
    Après avoir installé la CLI ( npm install -g netlify-cli ) et nous être connecté à notre compte Netlify ( ntl login ), nous pouvons accéder au répertoire racine de notre application, exécuter ntl init et suivre les étapes.
  2. Utilisation de l'application Web Netlify
    Nous devrions aller sur https://app.netlify.com/start. Connectez-vous à notre fournisseur Git, choisissez le référentiel de notre application dans la liste, configurez certaines options de construction et déployez.

Pour les deux méthodes, nous devons considérer que notre commande build sera la next build et que notre répertoire à déployer est out .

Enfin, le plugin Essential Next.js est installé automatiquement, ce qui nous permettra de déployer et d'utiliser les routes API, les routes dynamiques et le mode aperçu. Et voilà, notre application Next.js est opérationnelle dans un service d'hébergement CDN rapide et stable.

Conclusion

Dans cet article, nous avons évalué des sites Web à l'aide de la bibliothèque jQuery et nous les avons comparés à de nouveaux frameworks frontaux tels que React et Next.js. Nous avons défini comment nous pourrions commencer une migration, au cas où cela nous profiterait, vers un outil plus récent. Nous avons évalué différentes stratégies de migration et nous avons vu quelques exemples de scénarios que nous pourrions migrer vers des projets d'application Web Next.js. Enfin, nous avons vu comment déployer notre application Next.js sur Netlify et la rendre opérationnelle.

Lectures complémentaires et ressources

  • Migration Frankenstein : approche indépendante du cadre
  • Suppression de jQuery de l'interface GitHub.com
  • Premiers pas avec Next.js
  • Comment déployer des sites Next.js sur Netlify
  • Articles Next.js dans le blog Netlify