Chez Storyly , nous avons deux projets React très différents ; l'un est "tableau de bord", et l'autre est "studio".

Ces deux projets diffèrent par leur objectif ainsi que par leurs défis techniques. Le tableau de bord est un projet CMS où nos utilisateurs gèrent leurs applications, instances, groupes Story, paramètres et intégrations et voient leurs analyses. Le projet Studio, quant à lui, est un outil de conception ; il permet à nos utilisateurs de concevoir leurs histoires sur une toile vide en utilisant nos éléments prédéfinis.

Sur le plan technique, comme vous le devinerez également, le tableau de bord est principalement composé de données côté serveur et le studio de données principalement côté client. Ainsi, lors de la catégorisation, je me concentre sur les objectifs des projets plutôt que sur les seuls aspects techniques.

En tant que développeurs front-end, nous ne devrions pas prendre de décisions techniques uniquement sur les aspects techniques. Il y a tellement d'autres aspects à considérer, y compris l'équipe, les utilisateurs actuels et potentiels, l'avenir prévu du projet et la culture d'entreprise. Tous ces éléments auront un impact fondamental sur vos solutions techniques lors du processus de prise de décision.

Supposons que votre tâche consiste à choisir une solution de gestion d'état pour votre projet. Il y en a tellement, avec différents inconvénients et avantages. Il est prudent de dire que le sujet de la gestion de l'état dans l'écosystème frontal vient avec le plus grand nombre de solutions à côté du sujet "frameworks".

Si vous ne considérez que les avantages et les inconvénients techniques, les performances, la facilité d'utilisation de la solution et peut-être le nombre de validations, d'étoiles et de problèmes de la solution seront ce que vous vérifierez. Et ce sont tous des points valables lors du choix d'une bibliothèque.

Lorsque je regarde les solutions de gestion d'état à utiliser dans les deux bases de code d'un point de vue technique, je suis enclin à utiliser Zustand ou Jotai. Ils sont bien entretenus, incroyablement faciles à utiliser et performants. C'était une décision facile, n'est-ce pas ?

Eh bien, nous utilisions le tout-puissant Redux dans nos deux bases de code pour gérer son état, et j'avais besoin de simplifier cette partie du projet car elle devenait plus étendue que nécessaire. C'était la principale source de beaucoup de nos bogues. J'ai immédiatement pensé "Oh génial, nous devrions utiliser Zustand pour les deux projets car c'est incroyable!" mais ensuite j'ai pris du recul et j'y ai réfléchi un peu plus.

Processus de migration

Comme je l'ai expliqué au début, nos deux bases de code sont très différentes.

Le tableau de bord montre les données côté serveur à l'utilisateur avec des modifications et des modifications très subtiles des données côté serveur. Il existe de nombreuses pages contenant des données analytiques, des listes et des statistiques calculées. L'avenir de ce projet sera également similaire; un tableau de bord de type CMS avec de nombreuses statistiques et listes. J'ai donc dû envisager la mise en cache des données, l'invalidation du cache, les cascades réseau, les mises à jour de données en temps réel, les mises à jour optimistes, etc. Avec ces sujets à l'esprit, j'ai décidé que nous n'avions pas besoin de changer notre solution de gestion d'état (Redux ); nous devions simplement le supprimer du tableau de bord car nous n'avons pas besoin de "gérer" un état.

Ensuite, j'ai examiné les solutions de récupération de données telles que SWR , TanStack Query et RTK Query .

SWR n'a pas de flux de mutation stable et RTK Query est trop couplé à Redux Toolkit. J'ai donc avancé avec TanStack Query.

TanStack Query supprime la surcharge de gestion des données côté serveur avec ses flux de mise en cache, d'invalidation et de mutation. Il y a toujours un état à gérer, mais vous n'avez pas toujours besoin de le gérer vous-même. Nous avons donné ce poids lourd à TanStack Query et n'avons pas regardé en arrière. Nous utilisons Redux et TanStack Query en parallèle et déplaçons l'état Redux morceau par morceau vers la requête TanStack jusqu'à ce qu'il ne reste plus rien sur l'état Redux et que nous puissions le faire en toute sécurité yarn remove.

React Hooks nous permet de les utiliser en parallèle et de déplacer progressivement la logique entre eux :

Dans le studio, cependant, de nombreuses données purement côté client sont générées pour être envoyées au serveur. Vous pouvez complètement concevoir une histoire avec des éléments prédéfinis ; vous pouvez les déplacer dans le canevas, les redimensionner, modifier leur contenu en fonction de vos besoins, modifier l'image d'arrière-plan de l'histoire ou même mettre une vidéo en arrière-plan. Et les possibilités sont infinies avant d'envoyer les données finales au serveur pour les sauvegarder. Toutes ces fonctionnalités sont des données côté client jusqu'à ce que vous les enregistriez. Et après les avoir enregistrées et les modifier, ce sont à nouveau des données côté client dérivées des données côté serveur.

Nous devons également penser aux fonctionnalités possibles - la possibilité d'annuler les modifications, de créer des dessins à main levée, de concevoir des transitions entre les histoires... Les possibilités sont infinies, mais toutes les fonctionnalités possibles sont des données lourdes côté client. Nous devons donc «gérer» notre état ici pour une flexibilité maximale.

Pour le Studio, nous utilisions déjà une solution de gestion d'état, Redux. Alors, j'ai posé la question à mes coéquipiers : "Que devrions-nous utiliser pour réparer notre gestion d'état ?"

Après toutes les réponses, le chemin était clair : nous allons utiliser Redux Toolkit .

RTK (Redux Toolkit) est un ensemble d'outils de l'équipe Redux pour améliorer la qualité de vie des développeurs. Il simplifie la configuration du magasin et la gestion de plusieurs magasins à l'aide de tranches . Nous avons donc migré notre ancien état Redux vers la nouvelle architecture RTK. Nous gérons à la fois l'ancienne et la nouvelle architecture côte à côte et déplaçons des éléments d'état vers la nouvelle architecture tout en la refactorisant. Tout cela nous permet d'avancer rapidement et progressivement sans bloquer le flux de travail du produit.

Nous exécutons cette ancienne et cette nouvelle architecture en parallèle en transmettant un contexte React personnalisé aux fournisseurs Redux :

Gardez à l'esprit que lorsque vous transmettez un contexte personnalisé au fournisseur Redux, vous devez créer tous les crochets Redux associés avec les générateurs fournis et les utiliser dans votre code au lieu d'importer directement depuis le packagereact-redux :

Notre objectif à long terme est de supprimer complètement Redux du projet Dashboard et de supprimer «l'ancien» Redux du projet Studio. Nous nous dirigeons vers cet objectif en refactorisant chaque fichier que nous devons toucher tout en développant de nouvelles fonctionnalités et en corrigeant les bugs.

Ces transitions techniques importantes doivent être fluides et progressives principalement pour deux raisons : Premièrement, vous repensez le quotidien de votre équipe. Ils devraient être heureux de travailler avec ces changements, sinon leurs performances diminueront considérablement. D'un autre côté, s'ils aiment les outils qu'ils utilisent pour construire et que lesdits outils les aident au lieu de les bloquer, leurs performances augmenteront considérablement. Et deuxièmement, le produit doit continuer à être construit . Le spectacle doit continuer. Il doit y avoir de nouvelles fonctionnalités. Il faut que ça avance. Les transitions techniques ne doivent donc pas bloquer le développement du produit. Chaque changement doit être progressif.

Sommaire

Lorsque nous prenons des décisions techniques en tant que développeurs, nous devons tenir compte de tous les aspects du projet sur lequel nous travaillons et des besoins de l'équipe avec laquelle nous travaillons. C'est simplement parce que ces décisions techniques affectent l'équipe et tous ceux qui travaillent sur le projet, pas seulement les développeurs.

Les changements techniques doivent être progressifs à tout prix. Ces changements ne doivent pas bloquer le pipeline du produit, et donc son succès.

Et rappelez-vous toujours que pour qu'un développeur soit productif, vous devez lui donner les outils qui le rendent heureux.