Fermer

juillet 21, 2021

Comment migrer de jQuery vers Next.js —


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 offert par 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 seraient 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 au 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.
  • Des appels AJAX faciles à créer.
  • Effets et animations faciles à utiliser.

Au fil des ans, JavaScript a beaucoup changé et a ajouté plusieurs fonctionnalités que nous n'avions pas dans le passé. Avec la redéfinition et l'évolution de ECMAScriptcertaines 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 l'utilisateur des interfaces ont 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 dans la mémoire, alors que jQuery interagit directement avec le DOMde 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 existe un scénario curieux : même si ces frameworks frontend sont de plus en plus populaires au fil des ans, 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 migrer 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, en fin de compte, 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é de faire travailler les gens sur le projet.

Il existe de nombreux scénarios où nous ne le faisons pas. besoin (ou ne veut pas) de suivre l'architecture que les 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. La plupart des fonctionnalités offertes par jQuery peuvent être accomplies à l'aide de fonctions natives JavaScript moderneset probablement d'une manière plus performante.

Parlons de la façon dont nous pourrions arrêter d'utiliser jQuery et migrer notre site Web dans 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 jQuery ont été incluses (ou au moins une très similaire) aux dernières versions Web standard. Ainsi, étant donné que :

  • $(selector) pattern 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.[19659010]Au lieu de faire :

    $(selector).addClass(className);

    Nous pouvons faire :

    element.classList.add(className);
    • De nombreuses animations peuvent être effectuées directement en utilisant CSS, à la place 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 : opacité 400ms ;
    }
    
    .cacher {
      opacité : 0 ;
    }

    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({
      tapez : « POSTER »,
      URL : '/l'url',
      données : données
    });

    Nous pouvons faire :

    var request = new XMLHttpRequest();
    request.open('POST', '/l'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 Vanilla JavaScript Code Snippets.

    Identify Components

    Si nous utilisons jQuery dans notre application, nous doit 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, voire le recharger.

    L'idée serait de refactoriser le code JavaScript vivant dans les pages et de construire React Composants. Cela nous aidera à joindre le code associé et à composer des éléments qui feront partie d'une composition plus large. En faisant cela, 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 :

    Avec la logique suivante :

    var $btnAction = $("#btn-action");
    
    $btnAction.on("clic", fonction() {
      alert("Le bouton a été cliqué");
    });

    Nous pouvons le migrer vers un composant React :

    import React depuis 'react' ;
    
    function Composant Bouton() {
    
      laissez handleButtonClick = () => {
        alert('Bouton cliqué !')
      }
    
      retour 
    }
    

    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, car nous garderions toutes les parties synchronisées 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ètes que celles 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 volumineuse, 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 que cela prend. Et, si nous ne faisons pas une migration progressive, nous devons penser à combien de temps notre application sera indisponible.

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

    Migration rapide

    Une autre approche consiste à diviser l'application en plusieurs parties. 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 ne le faisons pas. attendre que la demande complète soit réécrite. Nous obtenons également un retour plus rapide des utilisateurs, ce qui nous permet de détecter les bogues ou les problèmes plus tôt.

    Mais une migration progressive nous pousse à avoir différents outils, bibliothèques, dépendances et frameworks. 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, car chacune des parties migrées pourrait fonctionner de manière différente, mais être affectée par le code qui définit global paramètres à notre système. Un exemple de ceci est l'utilisation d'une logique en cascade pour le style CSS.

    Imaginez que nous travaillons 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 plus tard. À quel point 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é.

    Frankenstein Migration

    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 : The Frankenstein Migration . Il base le processus de migration sur deux composants principaux : Microservices et Composants Web.

    Le processus de migration se compose d'une liste d'étapes à suivre :

    1. Identifier les microservices

    Sur la base de notre code d'application, nous devons 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'articles » et à un « 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 ne soyez pas affecté 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 remanier le fonctionnement de notre code.

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

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

    3. Write An Alien Component

    Réécrivez un service de notre application Host dans notre application Alien, en utilisant le nouveau framework. Le composant devrait 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 :

    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) {
        revenir;
      }
    
      // code pour ajouter l'élément à la liste
    
      $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())
        }
      }
    
      revenir
         setText(e.target.value)} onKeyDown={handleSubmit} />
    }
    

    4. Écrire un wrapper de composant Web autour du service Alien

    Créer un composant wrapper qui importe notre service Alien que nous venons 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 liste d'épicerie, nous pouvons créer un AddItem-wrapper.js dans le projet Host. Ce fichier contiendra le code qui enveloppe notre composant AddItem déjà créé et crée un élément personnalisé avec :

    import React from "../alien/node_modules/react" ;
    importer ReactDOM de "../alien/node_modules/react-dom" ;
    importer AddItem de "../alien/src/components/AddItem" ;
    
    la classe FrankensteinWrapper étend HTMLElement {
      connectéRappel() {
        const appWrapper = document.createElement("div");
        appWrapper.classList.add("grocerylistapp");
    
        ...
    
        ReactDOM.render(
          ,
          appWrapper
        );
    
        …
    
      }
    }
    
    customElements.define("frankenstein-add-item-wrapper", FrankensteinWrapper);

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

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

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

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

    Par

    
    
    ... 

    6. Rinse And Repeat

    Passez en revue les étapes 3, 4 et 5 pour chacun des microservices identifiés.

    7. Switch To Alien

    Host est désormais 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 devons juste diriger nos utilisateurs vers l'application Alien maintenant.

    La méthode de migration de Frankenstein fonctionne comme une combinaison des approches Good et Fast. Nous migrons l'application complète mais libérons 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 cependant considérer que nous travaillons un peu trop 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 hôte. 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.

    Strangler Application

    Une autre approche que nous pouvons adopter est la L'étranglement des applications héritées . Nous identifions les contours de notre application Web existante, et chaque fois que nous devons 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é, nous les enveloppons dans de nouveaux composants React. Nous n'ajoutons aucun comportement supplémentaire, nous créons simplement des composants React qui rendent notre contenu existant.

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

    Item 1

    Text 1

    Item 2

    Text 2

    Item 3

    Text 3
    >

    Et ce code JavaScript (nous avons déjà remplacé les fonctions jQuery par de nouvelles fonctionnalités standard JavaScript).

    const accordéons = document.querySelectorAll(".accordion");
    pour (const accordéon d'accordéons) {
      const panels = accordion.querySelectorAll(".accordion-panel");
      pour (const panneau de panneaux) {
        const head = panel.querySelector(".accordion-header");
        head.addEventListener('click', () => {
          for (const otherPanel of panels) {
            if (autrePanneau !== panneau) {
              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 accordéons = document.querySelectorAll(".accordion")
        pour (const accordéon d'accordéons) {
          const panels = accordion.querySelectorAll(".accordion-panel")
          pour (const panneau de panneaux) {
            const head = panel.querySelector(".accordion-header")
            head.addEventListener("click", () => {
              for (const otherPanel of panels) {
                if (autrePanneau !== panneau) {
                  otherPanel.classList.remove("accordéon étendu")
                }
              }
              panel.classList.toggle("accordion-expanded")
            });
          }
        }
      }, [])
    
      retourner null
    }
    
    ReactDOM.render(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.

    Ainsi, nous n'avons ajouté aucune nouvelle fonctionnalité à notre application existante, mais nous avons introduit React sans modifier son comportement. À partir de maintenant, chaque fois que nous ajoutons de nouvelles fonctionnalités ou modifications à 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 à l'aide du rendu côté serveur. Enfin, nous pouvons créer le contenu de notre page au moment de la construction à l'aide de la génération statique.

    Dans notre application, nous devrions charger et afficher le code lors du chargement de la page, avant de commencer à interagir avec une bibliothèque JavaScript ou cadre. 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. En faisant cela, nous gardons tout le comportement dans le 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.

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

    const DashboardPage = ({ user }) => {
      revenir (
        

    {user.name}

    // Données d'utilisateur
    ) } export const getServerSideProps = async ({ req, res, params }) => { revenir { accessoires : { utilisateur : getUser(), }, } }, }) export default DashboardPage

    Si le balisage que nous rendons au chargement de la page est prévisible et est 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érerons toutes les pages statiques pour nos articles de blog au moment de la création.

     export const getStaticPaths = async () => {
      const blogPosts = wait getBlogPosts()
    
      const paths = blogPosts.map(({ slug }) => ({
        paramètres : {
          limace,
        },
      }))
    
      revenir {
        chemins,
        repli : faux,
      }
    }
    
    export const getStaticProps = async ({ params }) => {
      const { slug } = paramètres
    
      const blogPost = wait getBlogPostBySlug(slug)
    
      revenir {
        accessoires : {
          données : JSON.parse(JSON.stringify(blogPost)),
        },
      }
    }

    Créer une API à l'aide de routes API

    L'une des fonctionnalités intéressantes offertes par Next.js est la possibilité de créer des routes API. 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 partira 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 en utilisant API Routes. En faisant cela, 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 routes API pour "masquer" les URL externes.

    Nous pourrions avoir une route API /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
    
      essayer {
        données const = getData(id)
        res.status(200).json(données)
      } capture (e) {
        res.status(500).json({ erreur : e.message })
      }
    }

    Et appelez-le à partir du code de notre page.

     const res = wait fetch(`/api/get/${id}`, {
        méthode : 'GET',
      })
    
      if (res.status === 200) {
        // Faire quelque chose
      } autre {
        console.error (attendre 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. Voici quelques faits saillants de Netlify :

    • Plateforme d'hébergement CDN mondiale,
    • Prise en charge des fonctions sans serveur,
    • Déployer des aperçus basés sur les requêtes d'extraction Github,
    • Webhooks,
    • Retours instantanés,
    • 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 Next. js app code dans un référentiel Git. Netlify se connecte à GitHub (ou à la plate-forme 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 Dépôt Git avec le code de notre application, nous devons créer un « site Netlify » pour cela. Pour ce faire, nous avons deux options :

    1. Utiliser Netlify CLI
      Après avoir installé la CLI (npm install -g netlify-cli) et nous connecter à notre compte Netlify (ntl login ), nous pouvons aller dans le répertoire racine de notre application, exécuter ntl init et suivre les étapes.
    2. Utiliser l'application Web Netlify
      Nous devrions aller à 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 de construction sera la prochaine version et 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 des routes API, des 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 avec de nouveaux frameworks frontend comme React et Next.js. Nous avons défini comment nous pourrions commencer une migration, au cas où cela nous serait avantageux, 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 faire fonctionner.

    Autres lectures et ressources

    Smashing Editorial(vf, yk, il)




Source link