Get best of the week

Redux Toolkit n'est plus nécessaire?

Le problème de l'énorme quantité de code passe-partout lors de l'utilisation de Redux est connu de tous, tout le monde le résout du mieux qu'il peut. Et nous avons utilisé différentes béquilles et vélos sur différents projets, sans perdre l'espoir de trouver quelque chose de standardisé et de pratique. Il y a un peu plus d'un an, nous désespérions de nos recherches et prenions sérieusement la solution du problème. Ce qui en est issu est décrit ci-dessous.

Histoire d'apparence


Notre entreprise développe des projets pour des startups du monde entier. Et pour ces gars fous inspirés, le plus important (ou l'un d'entre eux) est le temps. Entré auparavant sur le marché - plus de chances de survie. Par conséquent, nous essayons toujours de réduire le temps de développement sans sacrifier la qualité et de réduire le nombre d'erreurs causées par le facteur humain. Pour la plupart, nous choisissons quelque chose de standard et plus ou moins stable. Dans ce cas, rien de prêt n'a pu être trouvé, alors ils ont retroussé leurs manches et ont commencé à voir ce qui pouvait être pédalé ici.



Comme d'habitude, nous avons commencé par une description du problème et avons obtenu ce qui suit:

  • Chaque développeur a son propre accent subtil lors de l'écriture de code, il est difficile de réaliser la mise en œuvre du concept de «code dépersonnalisé»;
  • Beaucoup de code (passe-partout, copier-coller et tous les problèmes qui en découlent), 100+ lignes sur CRUD;
  • On passe beaucoup de temps à écrire des choses de base. Vous oublierez une chose, l'autre: définir le chargement, gérer les erreurs, etc.
  • La structure du magasin diffère d'un projet à l'autre et parfois entre différentes parties du projet.

Une question correctement posée ou un problème formulé représente la moitié de la solution. Après un peu de réflexion, nous avons introduit les règles de constitution du magasin, décrit sa structure et décidé de refactoriser et peigner le code. Malgré le fait que notre base de code n'était pas incroyablement grande, nous sommes immédiatement tombés sur la quantité de code qui doit être modifiée.

Alors que les PM se demandaient où trouver quelques heures de plus par jour, il y avait quelques passionnés qui ont généré et mis en œuvre une idée simple au point de la banalité. Oui, les idées ingénieuses, après leur apparition, semblent toujours simples. Et l'idée était la suivante: générer simplement des morceaux de code séparés au lieu de le réécrire manuellement. Je ne voulais pas utiliser d'extraits et obtenir des feuilles à la sortie, car tout changement a conduit à un désastre et à une refactorisation répétée, si rapidement scié une fonction qui a pris certains paramètres en entrée et construit un réducteur, une action et une saga. La première version des communications est donc née ( @ axmit / redux-communications) Le nom "communication" est né d'une manière ou d'une autre, car cette bibliothèque relie les sagas et les composants. Et c'est ainsi ...

Immédiatement après cela, le bonheur est venu. Eh bien, ou presque immédiatement. Le temps de développement a diminué d'environ 20% (comme nous l'avons calculé - le sujet d'un article séparé). Tout d'abord, en raison d'une réduction significative du nombre de bogues d'exploration. Et cela sans oublier le fait que les développeurs sont beaucoup moins susceptibles de commettre des erreurs stupides par inattention.



Linus Torvalds a dit un jour: «Chatter ne vaut rien. Montrez-moi le code. »Et je suis entièrement d'accord avec lui. Je ne citerai ni ne réécrirai le dock ni ne donnerai les feuilles de code ici.Je ne donnerai qu'un petit exemple. Des liens vers une description complète de la bibliothèque et un bac à sable avec des exemples peuvent également être trouvés à la fin de l'article.

Considérez une tâche typique - nous devons créer CRUD pour une entité. Prenons par exemple la tâche. Je considère inutile de décrire la version standard, car cela prendra beaucoup d'espace, et tous ceux qui ont rencontré l'éditeur sont susceptibles d'imaginer à peu près à quoi cela ressemblera. Et pour obtenir la communication, vous devez faire les choses suivantes:

1. Décrivez le transport, sans lui n'importe où

const basePath = `/api/task`;

const taskTransport = {
   add: task => axios.post(`basePath`, task).then(r => r.data),
   get: id => axios.get(`${basePath}/${id}`).then(r => r.data),
   update: task => axios.put(`${basePath}/${task.id}`, task).then(r => r.data),
   delete: id => axios.delete(`${basePath}/${id}`, task),
   getCollection: () => axios.get(basePath).then(r => r.data)
};

2. Décrire l'espace de noms
const namespace = 'task';

3. Créer une stratégie de création de communication
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});

4. Créer une communication
const taskCommunication = buildCommunication(strategy);

5. Connectez les réducteurs et les sagas de la communication, comme d'habitude
taskCommunication.reducers
taskCommunication.sagas

6. Après cela, il reste à connecter le côté au composant
taskCommunication.injector(MyComponent)

7. Et commencez à utiliser
componentDidMount() {
   const { getTaskCollection } = this.props;
   getTaskCollection();
}

render() {
   const { taskCollection } = this.props;
   return  taskCollection.data.map(item => <span>{item.title}</span>)
}

En fait, le transport et le composant devront être créés dans tous les cas, et le code de communication complet est le suivant:

import { taskTransport } from './task.transport';
import { CRUDStrategy, buildCommunication, StoreBranch } from '@axmit/redux-communications';
 
const namespace = 'task';
 
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});
 
export const taskCommunication = buildCommunication(strategy);


C'est tout ce que vous devez faire pour avoir un CRUD entièrement fonctionnel. Si vous devez faire quelque chose de plus compliqué, vous pouvez étendre la communication CRUD ou utiliser BaseCommunication. Dans un cas extrême, sous le capot, ce sont toujours les mêmes bons éditeurs à l'ancienne avec toutes ses fonctionnalités. La flexibilité n'a pas été affectée. Le transport est placé dans une couche distincte et son implémentation peut être n'importe quoi. Nous avons graphQL sur nos projets et requêtes simples utilisant axios, et nous n'avons rencontré aucune difficulté à cet égard. Un lecteur attentif a peut-être remarqué que la bibliothèque exporte des sagas, et c'est l'une de ses limites les plus importantes. Si, pour une raison quelconque, vous ne pouvez pas utiliser de sagas, cette bibliothèque, malheureusement, ne vous convient pas.

Pourquoi maintenant?


La décision d'écrire un article est venue après avoir lu cet article . En poussant cet outil, j'ai été surpris de constater que les communications sont beaucoup plus simples, plus concises, donnent une structure plus claire du magasin et en même temps ne sont pas inférieures en flexibilité. Après m'être assis et avoir trié une heure avec les sources de l'exemple vers la boîte à outils redux, je l'ai réécrite pour la communication. J'ai essayé de faire un minimum de changements pour faciliter le suivi de la différence, même si, à mon avis, la structure de l'exemple est très confuse. J'ai spécifiquement laissé des commentaires sur le code pour le rendre plus facile à comparer comment il était et comment il est devenu. Faites attention aux fichiers * et aux tranches * .communication.ts qu'ils remplacent.



Le fait que le nombre de lignes soit beaucoup plus petit et que le code lui-même soit beaucoup plus agréable (subjectif) n'est pas si important, car en prod, nous avons des communications assez lourdes. Il y a encore une différence importante. Le code est déclaratif. Nous déterminons simplement quoi et où nous voulons obtenir et quoi faire avec les données, et comment le faire - nous ne nous soucions pas du tout.
Conclusion - redux-toolkit doit être utilisé pour la personnalisation, pour tout le reste il y a MasterCa ... @ axmit / redux-communications .

Résumer


  • Le code est devenu cohérent dans tous les projets et avec tous les développeurs. Des problèmes similaires sont résolus de manière uniforme et les solutions sont souvent livrées dans des emballages séparés et réutilisées à l'avenir. Dans le même temps, la quantité de code a considérablement diminué.
  • Le mois de juin a reçu un flux clair et compréhensible.
  • Les personnes âgées se réjouissent de ne pas avoir à écrire des tonnes de code standard et réfléchissent à d'autres moyens d'améliorer les communications.
  • Le débogage a été simplifié et la structure du magasin est devenue simple et compréhensible pour tous les développeurs de l'entreprise.
  • La transition entre des projets ou différentes parties du système ne provoque pas de maux de tête.
  • Les PM sont également heureux. Le nombre de bugs a diminué - les clients sont satisfaits. L'écriture est devenue plus facile - les développeurs sont contents. De quoi d'autre PM a-t-il besoin pour être heureux?
  • Vous pouvez passer progressivement aux communications ou même utiliser une approche hybride (communications + tranches).

Bien sûr, la bibliothèque présente également des inconvénients.

  • Sans exemple de code et de documentation, il est assez difficile de le comprendre.
  • Changer la structure du magasin pour un arbitraire ne fonctionnera pas, car C'est sur la structure du magasin que toute l'automatisation est basée. Mais il convient de noter que dans notre travail, nous n'avons jamais rencontré de difficultés avec cela.
  • Vous ne pouvez travailler qu'avec des sagas. Thunk ne nous convenait pas, et nous utilisons toujours des sagas, donc ce n'est pas un problème pour nous. Mais si pour une raison quelconque, les sagas ne vous conviennent pas, vous ne pourrez pas utiliser la bibliothèque.

J'espère que, malgré les lacunes existantes, notre bibliothèque sera utile à quelqu'un. Si vous avez des suggestions d'amélioration ou des questions sur leur utilisation, veuillez écrire, je serai heureux de discuter.
S'il y a des analogues plus cool que nous n'avons pas pu trouver - faites le moi savoir, nous les étudierons certainement!

Une description complète de la bibliothèque peut être trouvée ici , et piquer en ligne ici .

Le code complet de l'exemple réécrit pour la communication à partir des docks ReduxToolkit est ici , mais vous pouvez le pousser ici .

More articles:


All Articles