Pourquoi est-ce un anti-modèle?

Bonjour. En septembre, plusieurs cours sur le développement JS débuteront à la fois chez OTUS, à savoir: Développeur JavaScript. Professionnel, développeur JavaScript. Développeur Basic et React.js. En prévision du début de ces cours, nous avons préparé une autre traduction intéressante pour vous, et nous vous proposons également de vous inscrire à des cours de démonstration gratuits sur les sujets suivants:

• Développement de bibliothèques de composants sur React + Storybook
• Développement piloté par les tests dans JS ou comment commencer à aimer la programmation
• Migrer un vrai projet de Javascript vers Typescript - douleurs et fonctionnalités

Passons maintenant à l'article.

---

Quand j'ai commencé à apprendre React, il y avait certaines choses que je ne comprenais pas. Et je pense que presque tous ceux qui connaissent React se posent les mêmes questions. J'en suis sûr parce que les gens créent des bibliothèques entières pour résoudre des problèmes urgents. Voici deux questions principales qui semblent intéresser presque tous les développeurs React:



Comment un composant accède-t-il aux informations (en particulier une variable d'état) qui se trouvent dans un autre composant? Comment un composant appelle-t-il une fonction qui se trouve dans un autre composant?



Les développeurs JavaScript en général (et les développeurs React en particulier) se sont de plus en plus tournés vers l'écriture de fonctions dites pures ces derniers temps. Fonctions qui ne sont pas associées aux changements d'état. Fonctions qui n'ont pas besoin de connexions de base de données externes. Des fonctions indépendantes de ce qui se passe en dehors d'elles.



Bien sûr, les fonctions pures sont un objectif noble. Mais si vous développez une application plus ou moins complexe, vous ne pourrez pas nettoyer toutes les fonctions. Il viendra certainement un moment où vous devrez créer au moins quelques composants qui sont en quelque sorte liés à d' autres composants. Essayer d'éviter cela est ridicule. Ces connexions entre les composants sont appelées dépendances .



En général, les dépendances sont mauvaises et ne sont mieux utilisées qu'en cas de besoin. Mais là encore, si votre application a grandi, certains de ses composants dépendront nécessairement les uns des autres. Bien sûr, les développeurs de React le savent, ils ont donc compris comment amener un composant à transmettre des informations critiques, ou des fonctions, à ses composants enfants.

Approche standard: utiliser des accessoires pour transmettre des valeurs

Toute valeur d'état peut être transmise à un autre composant via des accessoires. Toute fonction peut être transmise aux composants enfants via les mêmes accessoires. C'est ainsi que les descendants savent quelles valeurs d'état sont stockées dans l'arborescence et peuvent potentiellement appeler des actions dans les composants parents. Tout cela, bien sûr, est bon. Mais les développeurs de React sont préoccupés par un problème particulier.



La plupart des applications sont en couches. Dans les applications complexes, les structures peuvent être imbriquées très profondément. L'architecture générale pourrait ressembler à ceci:



App→ fait référence à → ContentArea

ContentArea→ fait référence à → MainContentArea

MainContentArea→ fait référence à → MyDashboard

MyDashboard→ fait référence à → MyOpenTickets

MyOpenTickets→ fait référence à → TicketTable

TicketTable→ fait référence à une séquence → TicketRow

Chaque TicketRow→ fait référence à →TicketDetail



Théoriquement, cette guirlande peut être enroulée pendant longtemps. Tous les composants font partie de l'ensemble. Plus précisément, une partie d'une hiérarchie. Mais ici, la question se pose:



le composant TicketDetailde l'exemple ci-dessus peut-il lire les valeurs d'état stockées ContentArea? Ou. Un composant peut-il TicketDetailappeler des fonctions qui se trouvent dans ContentArea?

La réponse aux deux questions est oui. En théorie, tous les descendants peuvent connaître toutes les variables stockées dans les composants parents. Ils peuvent également appeler des fonctions ancêtres - mais avec une grande mise en garde. Cela n'est possible que si ces valeurs (valeurs d'état ou de fonction) sont explicitement passées aux descendants via des accessoires. Sinon, l'état ou les valeurs de fonction du composant ne seront pas disponibles pour son composant enfant.



Dans les petites applications et utilitaires, cela ne joue pas un rôle particulier. Par exemple, si un composant a TicketDetailbesoin d'accéder aux variables d'état qui sont stockées dans TicketRow, il suffit de faire en sorte que le composant TicketRow→ passe ces valeurs à son descendant → TicketDetailvia un ou plusieurs accessoires. Il en va de même lorsqu'un composant TicketDetaildoit appeler une fonction qui se trouve dans TicketRow. Component TicketRow→ passera cette fonction à son descendant → TicketDetailvia prop. Le mal de tête commence lorsqu'un composant situé loin dans l'arborescence a besoin d'accéder à l'état ou à la fonction du composant en haut de la hiérarchie.



Pour résoudre ce problème dans React, les variables et les fonctions sont traditionnellement transmises à tous les niveaux. Mais cela encombre le code, prend des ressources et nécessite une planification sérieuse. Nous devrions passer des valeurs à de nombreux niveaux comme ceci:



ContentArea→ MainContentArea→ MyDashboard→ MyOpenTickets→ TicketTable→ TicketRow→ TicketDetail



C'est-à-dire que pour passer une variable d'état de ContentAreaà TicketDetail, nous devons faire beaucoup de travail. Les développeurs expérimentés comprennent qu'il existe une longue chaîne de valeurs et de fonctions qui passent comme accessoires à travers des niveaux intermédiaires de composants. La solution est si lourde que j'ai même abandonné l'apprentissage de React à plusieurs reprises à cause de cela.

Le monstre nommé Redux

Je ne suis pas le seul à penser que transmettre toutes les valeurs d'état et toutes les fonctions communes aux composants via des accessoires est très peu pratique. Il est peu probable que vous trouviez une application React complexe qui ne soit pas fournie avec un outil de gestion d'état. Il n’existe pas si peu d’outils de ce type. Personnellement, j'adore MobX. Malheureusement, Redux est considéré comme le "standard de l'industrie".



Redux est une idée originale des créateurs du noyau React. Autrement dit, ils ont d'abord créé une merveilleuse bibliothèque React. Mais ils ont tout de suite compris qu'il était presque impossible de gérer l'Etat avec ses moyens. S'ils n'avaient pas trouvé un moyen de résoudre les problèmes inhérents à cette bibliothèque (sinon géniale), beaucoup d'entre nous n'auraient jamais entendu parler de React.



Ils ont donc proposé Redux.

Si React est Mona Lisa, alors Redux est une moustache qui lui est attachée. Si vous utilisez Redux, vous devrez écrire une tonne de code standard dans presque tous les fichiers de projet. Le dépannage et la lecture du code deviennent un enfer. La logique métier est transférée dans la cour. Le code contient de la confusion et des hésitations.



Mais si les développeurs ont le choix: React + Redux ou React sans aucun outil de gestion d'état tiers , ils choisissent presque toujours React + Redux. Étant donné que la bibliothèque Redux a été développée par les auteurs principaux de React, elle est considérée comme une solution approuvée par défaut. Et la plupart des développeurs préfèrent utiliser des solutions qui ont été tacitement approuvées comme celle-ci.



Bien sûr, Redux créera tout un réseau de dépendancesdans votre application React. Mais, pour être honnête, tout outil de gestion d’État générique fera de même. L'outil de gestion d'état est un référentiel partagé de variables et de fonctions. Ces fonctions et variables peuvent être utilisées par tout composant ayant accès au stockage partagé. Cela présente un inconvénient évident: tous les composants deviennent dépendants du stockage partagé.



La plupart des développeurs React que je connais qui ont essayé de résister à l'utilisation de Redux ont finalement abandonné. (Parce que ... la résistance est inutile.) Je connais beaucoup de gens qui détestent immédiatement Redux. Mais quand ils ont été confrontés à un choix - Redux ou "nous trouverons un autre développeur React" - ils se sont jetésont accepté d'embrasser Redux comme partie intégrante de leur vie. C'est comme les impôts. Comme un examen rectal. Comme aller chez le dentiste.

Réagir aux valeurs partagées dans React

Je suis trop têtu pour abandonner si facilement. Après avoir regardé Redux, j'ai réalisé que je devais chercher d'autres solutions. Je peux utiliser Redux. Et j'ai travaillé dans des équipes qui utilisaient cette bibliothèque. En général, je comprends ce qu'elle fait. Mais cela ne veut pas dire que j'aime Redux.

Comme je l'ai dit, alors qu'un outil de gestion d'état séparé est indispensable, MobX est environ ... un million de fois meilleur que Redux! Mais je suis tourmenté par une question plus sérieuse. Cela touche l'esprit collectif des développeurs de React:



pourquoi nous saisissons toujours d'abord d'un outil de gestion d'état?



Lorsque j'ai commencé à développer avec React, j'ai passé de nombreuses nuits à chercher des solutions alternatives. Et j'ai trouvé un moyen que de nombreux développeurs React négligent, mais aucun d'entre eux ne peut dire pourquoi . Expliquera.



Imaginez que dans l'application hypothétique dont j'ai parlé ci-dessus, nous créons un fichier comme celui-ci:

// components.js
let components = {};
export default components;

Et c'est tout. Juste deux courtes lignes de code. Nous créons un objet vide - un bon vieil objet JS . Nous l'exportons par défaut avec export default.



Voyons maintenant à quoi pourrait ressembler le code à l'intérieur du composant <ContentArea>:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      components.ContentArea = this;
   }

   consoleLog(value) {
      console.log(value);
   }

   render() {
      return <MainContentArea/>;
   }
}

Pour la plupart, cela ressemble à un composant React basé sur des classes parfaitement normal. Nous avons une fonction simple render()qui accède au composant suivant dans l'arborescence. Nous avons une petite fonction console.log()qui imprime le résultat de l'exécution du code sur la console et un constructeur. Mais ... il y a quelques nuances dans le constructeur .



Au tout début, nous avons importé un objet simple components. Ensuite, dans le constructeur, nous avons ajouté une nouvelle propriété à l'objet componentsavec le nom du composant React actuel ( this). Dans cette propriété, nous faisons référence au composant this. Désormais, chaque fois que nous accédons à l'objet composants, nous aurons un accès direct au composant <ContentArea>.



Voyons ce qui se passe en bas de la hiérarchie. Le composant <TicketDetail>peut être comme ceci:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      components.ContentArea.consoleLog('it works');
      return <div>Here are the ticket details.</div>;
   }
}

Voici ce qui se passe. Chaque fois que le composant TicketDetailest rendu consoleLog(), la fonction stockée dans le composant sera appelée ContentArea.



Notez que la fonction n'est consoleLog()pas transmise à travers toute la hiérarchie via les accessoires. En fait, la fonction n'est consoleLog()transmise nulle part - ni nulle part - à aucun composant.



Et pourtant, il TicketDetailpeut appeler la fonction consoleLog()qui est stockée dans ContentArea, car nous avons fait deux choses:

1. ContentAreaUne fois chargé, le composant a ajouté un lien vers lui-même vers l'objet partagé des composants.
2. TicketDetailUne fois chargé, le composant importait un objet partagé components, c'est-à-dire qu'il avait un accès direct au composant ContentArea, malgré le fait que les propriétés n'étaient ContentAreapas transmises au composant TicketDetailvia des accessoires.

Cette approche ne fonctionne pas uniquement avec les fonctions / callbacks. Il peut être utilisé pour interroger directement les valeurs des variables d'état. Imaginons à quoi <ContentArea>ressemble ceci:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   render() {
      return <MainContentArea/>;
   }
}

Ensuite, nous pouvons écrire <TicketDetail>comme ceci:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return <div>Here are the ticket details.</div>;
   }
}

Désormais, chaque fois que le composant est rendu <TicketDetail, il recherchera la valeur de la variable state.reduxSucksdans <ContentArea>. Si la variable renvoie une valeur true, la fonction console.log()imprimera un message sur la console. Cela se produira même si la valeur de la variable ContentArea.state.reduxSucksn'a jamais été transmise dans l'arborescence - à aucun des composants - via des accessoires. Ainsi, avec un simple objet JS sous-jacent qui vit en dehors du cycle de vie standard de React, nous pouvons faire en sorte que tout descendant puisse lire les variables d'état directement à partir de n'importe quel parent chargé dans l'objet composants. On peut même appeler des fonctions du composant parent dans son descendant.



La possibilité d'appeler une fonction directement dans les composants enfants signifie que nous pouvons modifier l'état des composants parents directement à partir de leurs enfants. Par exemple comme ça.



Tout d'abord, dans le composant, <ContentArea>nous allons créer une fonction simple qui change la valeur d'une variable reduxSucks.

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   toggleReduxSucks() {
      this.setState((previousState, props) => {
         return { reduxSucks: !previousState.reduxSucks };
      });
   }

   render() {
      return <MainContentArea/>;
   }
}

Ensuite, dans le composant, <TicketDetail>nous appellerons cette méthode via l'objet components:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return (
         <>
            <div>Here are the ticket details.</div>
            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>
         </>
      );
   }
}

Désormais, après chaque rendu d'un composant, l' <TicketDetail>utilisateur pourra appuyer sur un bouton qui changera (basculera) la valeur de la variable ContentArea.state.reduxSucksen temps réel, même si la fonction ContentArea.toggleReduxSucks()n'a jamais été transmise dans l'arborescence via des accessoires.



Avec cette approche, le composant parent peut appeler la fonction directement à partir de son enfant. Voici comment procéder. Le composant mis à jour <ContentArea>ressemblera à ceci:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   toggleReduxSucks() {
      this.setState((previousState, props) => {
         return { reduxSucks: !previousState.reduxSucks };
      });
      components.TicketTable.incrementReduxSucksHasBeenToggledXTimes();
   }

   render() {
      return <MainContentArea/>;
   }
}

Ajoutons maintenant de la logique au composant <TicketTable>. Comme ça:

// ticket.table.js
import components from './components';
import React from 'react';
import TicketRow from './ticket.row';

export default class TicketTable extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucksHasBeenToggledXTimes: 0 };
      components.TicketTable = this;
   }

   incrementReduxSucksHasBeenToggledXTimes() {
      this.setState((previousState, props) => {
         return { reduxSucksHasBeenToggledXTimes: previousState.reduxSucksHasBeenToggledXTimes + 1};
      });      
   }

   render() {
      const {reduxSucksHasBeenToggledXTimes} = this.state;
      return (
         <>
            <div>The `reduxSucks` value has been toggled {reduxSucksHasBeenToggledXTimes} times</div>
            <TicketRow data={dataForTicket1}/>
            <TicketRow data={dataForTicket2}/>
            <TicketRow data={dataForTicket3}/>
         </>
      );
   }
}

En conséquence, le composant n'a <TicketDetail>pas changé. Cela ressemble toujours à ceci:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return (
         <>
            <div>Here are the ticket details.</div>
            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>
         </>
      );
   }
}

Avez-vous remarqué la bizarrerie associée à ces trois classes? Dans la hiérarchie de notre application ContentArea, il s'agit du composant parent pour TicketTable, qui est le composant parent pour TicketDetail. Cela signifie que lorsque nous montons un composant ContentArea, il ne "connaît" pas encore son existence TicketTable. Et la fonction toggleReduxSucks()écrite en ContentAreaappelle implicitement la fonction enfant:. Il

incrementReduxSucksHasBeenToggledXTimes()s'avère que le code ne fonctionnera pas , non?



Mais non.



Regardez. Nous avons créé plusieurs niveaux dans l'application, et il n'y a qu'une seule façon d'appeler la fonction toggleReduxSucks(). Comme ça.

1. Nous montons et rendons ContentArea.
2. Au cours de ce processus, une référence aux composants est chargée dans l'objet composants ContentArea.
3. Le résultat est monté et rendu TicketTable.
4. Au cours de ce processus, une référence aux composants est chargée dans l'objet composants TicketTable.
5. Le résultat est monté et rendu TicketDetail.
6. « reduxSucks» (Toggle reduxSucks).
7. « reduxSucks».
8. toggleReduxSucks(), ContentArea.
9. incrementReduxSucksHasBeenToggledXTimes() TicketTable .
10. , , « reduxSucks», TicketTable components. toggleReduxSucks() ContentArea incrementReduxSucksHasBeenToggledXTimes(), TicketTable, components.

Il s'avère que la hiérarchie de notre application nous permet d'ajouter un ContentAreaalgorithme au composant qui appellera une fonction à partir du composant enfant, malgré le fait que le composant ContentAreane connaissait pas l'existence du composant lors de son montageTicketTable .

Outils de gestion de patrimoine - Dump

Comme je l'ai expliqué, je suis profondément convaincu que Redux n'est pas à la hauteur de MobX. Et quand j'ai le privilège de travailler sur un projet à partir de zéro (malheureusement pas souvent), je fais toujours campagne pour MobX. Pas pour Redux. Mais lorsque je développe mes propres applications , j'utilise rarement des outils de gestion d'état tiers - presque jamais . Au lieu de cela, je mets simplement en cache des objets / composants chaque fois que possible. Et si cette approche ne fonctionne pas, je reviens souvent à la solution par défaut dans React, c'est-à-dire que je ne fais que passer des fonctions / variables d'état via des accessoires.

"Problèmes" connus avec cette approche

Je suis bien conscient que mon idée de mettre en cache l'objet sous-jacent n'est componentspas toujours adaptée pour résoudre les problèmes d'état / de fonction partagés. Parfois, cette approche peut ... jouer une blague cruelle . Ou cela pourrait ne pas fonctionner du tout . Voici quelque chose à garder à l'esprit.

• Cela fonctionne mieux avec les célibataires .
  
  
  
  Par exemple, dans notre hiérarchie, le composant <TicketTable> contient des composants <TicketRow> avec une relation zéro à plusieurs. Si vous souhaitez mettre en cache la référence à chaque composant potentiel dans les composants <TicketRow> (et leurs composants enfants <TicketDetail>) dans le cache des composants, vous devez les stocker dans un tableau, ce qui peut devenir délicat. J'ai toujours évité cela.
• components , / , components. .
  
  , . , , . / , , components.
• , components, ( setState()), setState(), .

Maintenant que j'ai expliqué mon approche et certaines de ses limites, je dois vous prévenir. Depuis que j'ai découvert cette approche, je la partage avec des personnes qui se considèrent comme des développeurs React professionnels. A chaque fois, ils répondent la même chose:



Hmm ... Ne fais pas ça. Ils froncent les sourcils et agissent comme si je venais de gâcher l'air. Quelque chose dans mon approche leur semble ... faux . Et en même temps, personne ne m'a encore expliqué, sur la base de sa riche expérience pratique, ce qui ne va pas exactement. C'est juste que tout le monde considère mon approche ... comme un blasphème .



Par conséquent, même si vous aimez cette approche ou si vous la trouvez pratique dans certaines situations, je ne recommande pasparlez-en lors d'un entretien si vous souhaitez décrocher un emploi de développeur React. Je pense que même en parlant à d'autres développeurs React, il faut réfléchir un million de fois avant de parler de cette méthode, ou peut-être qu'il vaut mieux ne rien dire du tout.



J'ai trouvé que les développeurs JS - et les développeurs React en particulier - peuvent être trop catégoriques . Parfois, ils expliquent pourquoi l'approche A est «mauvaise» et l'approche B est «juste». Mais dans la plupart des cas, ils regardent simplement un morceau de code et le déclarent «mauvais», même s'ils ne peuvent pas eux-mêmes expliquer pourquoi.

Alors, pourquoi cette approche est-elle si ennuyeuse pour les développeurs React?

Comme je l'ai dit, aucun de mes collègues ne pouvait raisonnablement expliquer pourquoi ma méthode est mauvaise. Et si quelqu'un est prêt à m'honorer avec une réponse, c'est généralement l'une des excuses suivantes (il y en a peu).

• , .
  
  
  
  .... , , Redux ( MobX, ) / React-. , . — . , /, . : , components. , / components, / , components. /, components , components . , , . , , Redux, MobX, - .
• React « ». … .
  
  
  
  … . ? , . — - « » « », , , . React, . , . . « », . , React 100 %, ( ) , .

, ?

J'ai écrit ce post parce que j'utilise cette approche depuis des années (dans des projets personnels). Et cela fonctionne très bien . Mais chaque fois que je sors de ma bulle personnelle et que j'essaye d'avoir une conversation intelligente sur cette approche avec d'autres développeurs React tiers , je ne rencontre que des déclarations catégoriques et des jugements idiots sur les «normes de l'industrie».



Cette approche est- elle vraiment mauvaise ? Eh bien, vraiment. Je veux savoir. S'il s'agit bien d'un «anti-modèle», je serai extrêmement reconnaissant à ceux qui justifieront son inexactitude. La réponse «je ne suis pas habitué à cela» ne me conviendra pas. Non, je ne suis pas coincé avec cette méthode. Je ne dis pas que c'est une panacée pour les développeurs React. Et j'avoue que cela ne fonctionne pas pour toutes les situations. Mais peut-êtrequelqu'un peut-il m'expliquer ce qui ne va pas avec ça?



Je veux vraiment connaître votre opinion à ce sujet - même si vous me faites exploser en mille morceaux.

Cours gratuits:

• Développement de bibliothèques de composants sur React + Storybook
• Développement piloté par les tests dans JS ou comment commencer à aimer la programmation
• Migrer un vrai projet de Javascript vers Typescript - douleurs et fonctionnalités