Comment maintenir une grande application Next.js —

Dans cet article, Nirmalya aborde certains des problèmes complexes auxquels il a été confronté lors de la création et de la maintenance de grandes applications Next.js. Il explique toujours comment ces problèmes peuvent être résolus en utilisant divers outils.

Maintenir une grande application est toujours une tâche difficile. Il peut avoir des dépendances obsolètes qui peuvent causer des problèmes de maintenabilité. Il peut aussi avoir des tests qui sont floconneux et n'inspirent aucune confiance. Il peut également y avoir des problèmes avec les gros bundles JavaScript et CSS, ce qui fait que l'application fournit une expérience utilisateur non optimale pour les utilisateurs finaux.

Cependant, il existe plusieurs façons de rendre une grande base de code facile à utiliser. maintenir. Dans cet article, nous discuterons de quelques-unes de ces techniques ainsi que de certaines des choses que j'aurais aimé savoir plus tôt pour aider à gérer les grandes applications Next.js.

Remarque : Pendant que cela article est spécifique à Next.js, certains des points fonctionneront également pour une grande variété d'applications frontales.

Utilisez TypeScript

TypeScript est un langage de programmation fortement typé, ce qui signifie qu'il applique une certaine rigueur tout en mélangeant différents types de données. Selon StackOverflow Developer Survey 2021TypeScript est l'un des langages avec lesquels les développeurs souhaitent le plus travailler.

L'utilisation d'un langage fortement typé comme TypeScript sera très utile pour travailler. avec une grande base de code. Cela vous aidera à comprendre s'il y a une possibilité que votre application échoue en cas de changement. Il n'est pas garanti que TypeScript se plaigne toujours en cas de risque de casse. Cependant, la plupart du temps, TypeScript vous aidera à éliminer les bogues avant même de créer votre application. Dans certains cas, la construction échouera s'il y a des incompatibilités de type dans votre code car Next.js vérifie la définition de type pendant la construction. , Next.js effectuera une vérification de type dans le cadre de la prochaine génération. Nous vous recommandons d'utiliser la vérification du type de l'éditeur de code pendant le développement. »

Notez que next build est le script qui crée une version de production optimisée de votre application Next.js. D'après mon expérience personnelle, cela m'a beaucoup aidé lorsque j'essayais de mettre à jour Next.js vers la version 11 pour l'une de mes applications. Dans le cadre de cette mise à jour, j'ai également décidé de mettre à jour quelques autres packages. Grâce à TypeScript et VSCode, j'ai pu déterminer quand ces changements étaient importants avant même d'avoir construit l'application.

Utilisez une structure mono-repo à l'aide de Lerna ou Nx

Imaginez que vous créez une bibliothèque de composants avec votre application Next.js principale. Vous souhaiterez peut-être conserver la bibliothèque dans un référentiel séparé pour ajouter de nouveaux composants, les créer et les publier sous forme de package. Cela semble propre et fonctionne bien lorsque vous souhaitez travailler dans la bibliothèque. Mais lorsque vous souhaitez intégrer la bibliothèque dans votre application Next.js, l'expérience de développement en souffrira.

En effet, lorsque vous intégrez la bibliothèque de composants à votre application Next.js, vous devrez peut-être retournez dans le référentiel de la bibliothèque, apportez des modifications, publiez les mises à jour, puis installez la nouvelle version dans votre application Next.js. Ce n'est qu'après cela que les nouvelles modifications de la bibliothèque de composants commenceront à se refléter dans l'application Next.js. Imaginez que toute votre équipe fasse cela plusieurs fois. Le temps consacré à la création et à la publication de la bibliothèque de composants séparément représentera une énorme partie.

Ce problème peut être résolu si vous utilisez une structure mono-repo où votre bibliothèque de composants réside avec votre Next.js demande. Dans ce cas, vous pouvez simplement mettre à jour votre bibliothèque de composants et cela se reflétera immédiatement dans votre application Next.js. Il n'est pas nécessaire de créer et de publier séparément votre bibliothèque de composants.

Vous pouvez utiliser un package tel que next-transpile-modules afin que vous n'ayez même pas besoin de créer votre bibliothèque de composants avant votre L'application Next.js peut le consommer. Cependant, si vous envisagez de publier votre bibliothèque de composants en tant que package npm, vous devrez peut-être avoir une étape de construction.

Pour gérer un mono-repo, vous pouvez utiliser des outils tels que LernaNxRushTurborepoyarn workspacesou npm workspaces. J'ai aimé utiliser Lerna avec des espaces de travail de fil lorsque j'avais besoin de configurer mon pipeline de construction. Si vous préférez quelque chose qui automatisera un tas de choses via CLI, vous pouvez jeter un œil à Nx. Je pense qu'ils sont tous bons mais résolvent des problèmes légèrement différents.

Utilisez des générateurs de code comme Hygen pour générer du code standard sera beaucoup de code en double. Cela se produit principalement parce qu'il est nécessaire de créer une page, un composant ou une fonction utilitaire similaire à une fonction déjà existante avec de légères modifications.

Vous pouvez penser à écrire des cas de test unitaires pour vos composants ou des fonctions utilitaires. Vous voudrez peut-être copier le code passe-partout autant que possible et apporter certaines modifications en fonction du nouveau fichier. Cependant, cela ajoute beaucoup de code consistant en un mauvais nom de variable dans votre base de code. Cela peut être réduit par un processus de révision de code approprié. Cependant, il existe un meilleur moyen de réduire cela en automatisant la génération du code standard. génération. J'ai utilisé Hygen pour générer le code passe-partout pour les composants Redux, React et les fonctions utilitaires. Vous pouvez consulter la documentation pour démarrer avec Hygen. Ils ont également une section dédiée pour générer le passe-partout Redux. Vous pouvez également utiliser Redux Toolkit pour réduire le code passe-partout nécessaire à vos applications Redux. Nous discuterons ensuite de ce paquet.

De nombreux développeurs diront que Redux augmente la complexité de la base de code ou que React Context est beaucoup plus facile à maintenir. Je pense que cela dépend principalement du type d'application que vous construisez ainsi que de l'expertise de toute l'équipe de développement. Vous pouvez choisir la solution de gestion d'état avec laquelle votre équipe est la plus à l'aise, mais essayez d'en choisir une qui n'a pas besoin d'avoir beaucoup de passe-partout.

Dans cet article, je mentionne Redux car il l'est toujours la solution de gestion d'état la plus populaire selon les tendances npm. Dans le cas de Redux, vous pouvez réduire beaucoup de code passe-partout en utilisant Redux Toolkit. Il s'agit d'une bibliothèque très avisée et puissante que vous pouvez utiliser pour simplifier votre gestion d'état. Consultez leur documentation sur la façon de démarrer avec Redux Toolkit.

J'ai utilisé Redux, Zustand et Redux Toolkit lors de la création d'applications Next.js. Je pense que Zustand est très simple et facile à comprendre. Cependant, j'utilise toujours Redux au cas où j'aurais besoin de construire quelque chose de complexe. Je n'ai pas utilisé XState mais c'est aussi un choix populaire. le rendre sur la page. Dans une application Next.js ou n'importe quelle application JavaScript, vous pouvez récupérer des données à l'aide de l'API Fetch Axios ou des bibliothèques similaires. Cependant, à mesure que l'application grandit, il devient très difficile de gérer cet état asynchrone de vos données. Vous pouvez créer vos abstractions à l'aide de fonctions utilitaires ou de wrappers autour de Fetch ou Axios, mais lorsque plusieurs développeurs travaillent sur la même application, ces fonctions utilitaires ou wrappers deviendront bientôt difficiles à gérer. Votre application peut également souffrir de problèmes de mise en cache et de performances.

Pour résoudre ce type de problèmes, il est préférable d'utiliser des packages tels que React Query ou SWR. Ces packages fournissent un ensemble par défaut de configurations prêtes à l'emploi. Ils gèrent beaucoup de choses comme la mise en cache et les performances qui sont difficiles à gérer par vous-même. Ces deux packages fournissent certaines configuration par défaut et options que vous pouvez utiliser pour personnaliser leurs comportements en fonction des exigences de votre application. Ces packages récupèreront et mettront en cache les données asynchrones de vos points de terminaison d'API back-end et rendront l'état de votre application beaucoup plus facile à gérer.

J'ai utilisé à la fois React Query et SWR dans mes projets et j'aime les deux. Vous pouvez jeter un œil à leur comparaison et à leurs fonctionnalités pour décider laquelle vous devez utiliser.

Utilisez Commitizen And Semantic Release avec Husky

Si vous déployez et publiez votre application souvent, vous pourriez avoir rencontré des problèmes avec la gestion des versions. Lorsque vous travaillez sur une grosse application et que plusieurs développeurs y contribuent, la gestion des versions devient encore plus difficile. Il devient très difficile de garder une trace du changelog. La mise à jour manuelle du journal des modifications devient très difficile et lentement, votre journal des modifications devient obsolète.

Vous pouvez combiner des packages tels que Commitizen et Semantic Release pour vous aider avec la gestion des versions et la maintenance d'un journal des modifications. Ces outils vous aident à automatiser une partie de votre processus de publication en synchronisant le journal des modifications avec les modifications déployées dans une version particulière. Vous pouvez utiliser un outil tel que Husky pour vous assurer que tous les contributeurs suivent le modèle établi pour rédiger des messages de validation et vous aider à gérer votre journal des modifications.

Utiliser Storybook pour visualiser les composants de l'interface utilisateur

Dans un grande base de code, votre application sera très probablement composée de nombreux composants. Certains de ces composants seront obsolètes, buggés ou ne seront plus nécessaires. Cependant, il est très difficile de garder une trace de ce genre de chose dans une grande application. Les développeurs peuvent créer de nouveaux composants dont le comportement peut être similaire à un composant déjà existant, car ils ne savent pas que le composant précédent existe. Cela se produit souvent car il n'y a aucun moyen de garder une trace des composants de l'application actuellement et de la façon dont ils interagissent les uns avec les autres. dont se compose actuellement votre base de code . La configuration de Storybook est simple et peut s'intégrer à votre application Next.js existante. Next.js contient un exemple qui montre comment configurer Storybook avec votre application.

J'ai toujours aimé utiliser Storybook car il aide mon équipe de développeurs à comprendre le comportement de chaque composant et les API qu'il expose. Il sert de source de documentation pour chaque développeur. Storybook aide également les concepteurs à comprendre le comportement de tous les composants et interactions. Vous pouvez également utiliser Chromatic avec Storybook pour les tests visuels et détecter les problèmes de régression au cours de chaque version.

Lecture recommandée : “Créer des applications React avec Storybook » par Abdulazeez Adeshina

Écrire des tests maintenables depuis le début

Écrire des tests prend du temps. En conséquence, de nombreuses entreprises ont tendance à ne pas investir de temps dans la rédaction de tests. De ce fait, l'application peut en souffrir à long terme. Au fur et à mesure que l'application grandit, la complexité de l'application augmente également. Dans une application complexe, la refactorisation devient difficile car il est très difficile de comprendre quels fichiers peuvent se briser à cause des modifications.

Une solution à ce problème serait d'écrire autant de tests que possible dès le début . Vous pouvez suivre Test Driven Development (ou TDD) ou tout autre concept similaire qui fonctionne pour vous. Il existe un excellent article The Testing Trophy and Testing Classifications de Kent C. Dodds qui parle des différents types de tests que vous pouvez écrire.

Bien que l'écriture de tests maintenables prenne du temps. Mais je pense que les tests sont très essentiels pour les grandes applications car ils donnent aux développeurs la confiance nécessaire pour refactoriser les fichiers. En règle générale, j'utilise JestReact Testing Library et Cypress pour écrire des tests dans mon application.

Utiliser Dependabot pour mettre à jour les packages automatiquement

Quand plusieurs équipes techniques contribuent à la même application, il y a de fortes chances que les packages utilisés deviennent obsolètes. Cela se produit parce que s'il y a des modifications importantes lors de la mise à jour des packages, il est possible qu'un temps considérable doive être investi dans cette mise à jour. Cela peut entraîner le non-respect des délais pour les fonctionnalités d'expédition. Cependant, cette pratique pourrait nuire à long terme. Travailler avec des packages obsolètes peut causer de nombreux problèmes tels que des failles de sécurité, des problèmes de performances, etc.

Heureusement, des outils tels que Dependabot peuvent aider votre équipe en automatisant le processus de mise à jour . Dependabot peut être configuré pour rechercher les packages obsolètes et envoyer des demandes d'extraction mises à jour aussi souvent que vous le souhaitez. L'utilisation d'outils tels que Dependabot m'a beaucoup aidé à maintenir à jour les dépendances de mes applications. Cependant, le plus important est d'aller à la section Production de la documentation Next.js . Cette section décrit certaines des choses les plus importantes que l'on doit implémenter avant de déployer une application Next.js en production . Avant de lire cette section, j'avais l'habitude de deviner arbitrairement ce qu'il fallait faire avant de déployer une application en production.

Vérifiez toujours quels navigateurs vous devez prendre en charge avant de déployer votre application en production et de les envoyer à vos clients. Next.js prend en charge une large gamme de navigateurs. Mais il est essentiel de comprendre à quel type d'utilisateurs vous envoyez votre application et quel type de navigateurs ils utilisent.

Conclusion

Ce sont certaines des choses que j'ai apprises lors de la création et de la maintenance d'une grande application Next.js . La plupart de ces points s'appliqueront à toute application frontale. Pour toute application frontale, la priorité principale doit toujours être de livrer un produit offrant une très bonne expérience utilisateur, rapide et agréable à utiliser.

J'essaie de garder tous ces points à l'esprit chaque fois que je développe une application. . J'espère qu'ils vous seront également utiles !

(vf, yk, il)