Questions existentielles sur React et dialogue modal parfait

Selon vous, quelle est la chose la plus compliquée dans React ? Re-rendu? Contexte? Des portails ? Concurrence ?

Non.

La partie la plus difficile de React est tout ce non-React qui l'entoure. La réponse à la question « Comment fonctionnent les éléments énumérés ci-dessus ? » est simple : il s'agit simplement de suivre l'algorithme et de prendre des notes. Le résultat sera définitif et toujours le même (si vous le tracez correctement). C'est juste de la science et des faits.

Mais qu'en est-il de « Qu'est-ce qui rend un composant bon ? » ou "Quelle est la bonne façon de mettre en œuvre… (quelque chose) ?" ou même « Dois-je utiliser une bibliothèque ou créer ma propre solution ? » La seule réponse factuellement correcte ici est « Cela dépend ». Il se trouve que c'est le moins utile.

Je voulais trouver quelque chose de mieux que ça pour le nouvel article. Mais comme il ne peut y avoir de réponses simples ni de solutions universelles à ce type de questions, l'article s'est avéré être davantage un aperçu de mon processus de réflexion plutôt que « c'est la réponse, faites-le toujours ». J'espère que c'est toujours utile.

Alors, que faut-il pour faire passer une fonctionnalité d'une idée à une solution prête pour la production ? Essayons d'implémenter une boîte de dialogue modale simple et voyons. Qu’est-ce qui peut bien être compliqué là-dedans ? ?

Étape 1 : Commencez par la solution la plus simple

Commençons par ce que l'on appelle parfois un « pic » : la mise en œuvre la plus simple possible qui peut aider à explorer des solutions potentielles et à rassembler d'autres exigences. Je sais que j'implémente un dialogue modal. Supposons que j'ai un joli design comme celui-ci :

Une boîte de dialogue est essentiellement un élément sur l'écran qui apparaît lorsque l'on clique sur quelque chose comme un bouton. C'est donc exactement par là que je vais commencer.

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

État, un bouton qui écoute les clics et une future boîte de dialogue qui s'affiche lorsque l'état est vrai. Le dialogue est également censé avoir une action "fermer":

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

Il a également une "toile de fond" - un div semi-transparent cliquable qui superpose le contenu et déclenche la disparition du modal lorsque vous cliquez dessus.

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

Tous ensemble :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

J'ajoute aussi généralement des styles décents dès le début. Voir la fonctionnalité que j'implémente apparaître à l'écran avec le même aspect qu'elle est censée m'aide à réfléchir. De plus, cela peut informer la disposition de la fonctionnalité, ce qui est exactement ce qui se passera avec cette boîte de dialogue.

Ajoutons rapidement du CSS pour le background - ce n'est rien de spécial, juste un fond semi-transparent sur un div avec position:fixe qui prend tout l'écran :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

La boîte de dialogue est légèrement plus intéressante puisqu'elle doit être positionnée au milieu de l'écran. Il existe bien sûr 1001 façons d'y parvenir en CSS, mais ma préférée et probablement la plus simple est la suivante :

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

Nous utilisons une position "fixe" pour échapper aux contraintes de mise en page, ajoutons 50 % à gauche et en haut pour déplacer le div au milieu et le transformons en arrière de 50 %. La gauche et le haut seront calculés par rapport à l'écran, et la transformation sera relative à la largeur/hauteur du div lui-même, donc par conséquent, il apparaîtra en plein milieu quelle que soit sa largeur ou la largeur de l'écran.

Le dernier élément CSS de cette étape consiste à styliser correctement la boîte de dialogue elle-même et le bouton "Fermer". Je ne vais pas le copier-coller ici, les styles réels ne sont pas si importants, jetez simplement un œil à l'exemple :

Étape 2 : arrêtez-vous, posez des questions et réfléchissez

Maintenant que j'ai une implémentation approximative de la fonctionnalité, il est temps de la rendre « réelle ». Pour ce faire, nous devons comprendre en détail ce que nous essayons exactement de résoudre ici et pour qui. Techniquement parlant, il faut comprendre que avant de coder quoi que ce soit, donc bien souvent, cette étape doit être l'Étape 1.

Ce dialogue fait-il partie d'un prototype qui doit être mis en œuvre le plus rapidement possible, montré une seule fois aux investisseurs et ne plus jamais être utilisé ? Ou peut-être que cela fait partie d'une bibliothèque générique que vous allez publier sur npm et open source ? Ou peut-être que cela fait partie des systèmes de conception que votre organisation de 5 000 personnes utilisera ? Ou fait-il partie de l'outillage interne de votre petite équipe de 3 personnes et rien d'autre ? Ou peut-être travaillez-vous pour quelque chose comme TikTok, et cette boîte de dialogue fera partie de l'application Web disponible uniquement sur mobile ? Ou peut-être travaillez-vous pour une agence qui écrit des applications uniquement pour le gouvernement ?

Répondre à ces questions détermine la direction à suivre en matière de codage.

S'il ne s'agit que d'un prototype à utiliser une seule fois, cela pourrait déjà suffire.

S'il doit être open source dans le cadre d'une bibliothèque, il doit disposer d'une très bonne API à usage général que tout développeur dans le monde peut utiliser et comprendre, de nombreux tests et une bonne documentation.

Le dialogue qui fait partie des systèmes de conception d'une organisation de 5 000 personnes doit respecter les directives de conception de l'organisation et peut être limité quant aux dépendances externes introduites dans le dépôt. Ainsi, vous devrez peut-être implémenter beaucoup de choses à partir de zéro plutôt que de faire npm install new-fancy-tool.

Le dialogue d'une agence qui construit pour le gouvernement doit probablement être le dialogue le plus accessible et le plus conforme aux réglementations de l'univers. Sinon, l'agence pourrait perdre les contrats gouvernementaux et faire faillite.

Et ainsi de suite et ainsi de suite.

Pour les besoins de cet article, supposons que la boîte de dialogue fait partie d'une nouvelle refonte, actuellement en cours, d'un grand site Web commercial existant avec des milliers d'utilisateurs quotidiens du monde entier. La refonte est tellement en cours que la seule conception avec la boîte de dialogue que j'ai obtenue est la suivante :

Le reste viendra plus tard, les créateurs sont débordés. De plus, je fais partie de l'équipe permanente qui effectue la refonte et maintient le site Web à l'avenir, et non un entrepreneur externe embauché pour un seul projet.

Dans ce cas, avoir seulement cette image et connaître l'objectif de notre entreprise me donne suffisamment d'informations pour faire des hypothèses raisonnables et mettre en œuvre 90 % du dialogue. Le reste des 10 % pourra être affiné ultérieurement.

Voici les hypothèses que je peux faire sur la base des informations ci-dessus :

• Le site Web existant compte quotidiennement des milliers d'utilisateurs du monde entier, je dois donc m'assurer que la boîte de dialogue, au minimum, fonctionne à la fois sur les écrans grands et mobiles, ainsi que sur différents navigateurs. Idéalement, je dois vérifier les analyses existantes pour en être absolument sûr, mais c'est une valeur assez sûre.

• Plusieurs développeurs écrivent du code pour cela, et le code est là pour rester. Le site Web est vaste et compte déjà des milliers d’utilisateurs ; ce n'est pas un prototype rapide pour les investisseurs. Je dois donc m'assurer que le code est lisible, que l'API a du sens, qu'elle est utilisable et maintenable, et qu'elle n'a pas de pistolets évidents.

• L'entreprise se soucie de son image et de la qualité de son site Web - sinon, pourquoi procéderait-elle à une refonte ? (Supposons ici une intention positive ?). Cela signifie qu'un certain niveau de qualité est attendu, et je dois anticiper et anticiper les scénarios courants et les cas extrêmes, même s'ils ne font pas encore partie de la conception actuelle.

• De nombreux utilisateurs veulent probablement dire qu'ils n'utilisent pas tous exclusivement la souris pour interagir avec le site Web. La boîte de dialogue doit également être disponible via des interactions au clavier et peut-être même des technologies d'assistance telles que des lecteurs d'écran.

• Une grande base de code existante (c'est une refonte, rappelez-vous !) signifie qu'il existe probablement des restrictions sur les dépendances externes que je peux apporter pour cette fonctionnalité. Toute dépendance externe a un coût, en particulier dans les bases de code volumineuses et anciennes. Pour les besoins de l'article, supposons que je puisse utiliser une bibliothèque externe, mais j'aurais besoin d'une bonne justification pour cela.

• Enfin, d'autres conceptions arrivent, je dois donc anticiper la direction que cela peut prendre du point de vue de la conception et de l'utilisateur et m'assurer que le code peut le gérer dès le début.

Étape 3 : solidifier l'API de dialogue modal

Maintenant que je connais les exigences et que j'ai des suppositions raisonnables, je peux créer le composant de dialogue proprement dit. Tout d'abord, à partir de ce code :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

Je dois absolument extraire la partie de dialogue dans un composant réutilisable - il y aura de nombreuses fonctionnalités basées sur les boîtes de dialogue à implémenter.

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

La boîte de dialogue aura un accessoire onClose - elle avertira le composant parent lorsque le bouton "fermer" ou l'arrière-plan sera cliqué. Le composant parent aura alors toujours l'état et affichera la boîte de dialogue comme ceci :

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

Maintenant, regardons à nouveau le design et réfléchissons davantage aux dialogues :

Il y aura clairement une partie "pied de page" de la boîte de dialogue avec des boutons d'action. Il y aura très probablement de nombreuses variantes de ces boutons : un, deux, trois, alignés à gauche, à droite, avec un espace entre les deux, etc. De plus, cette boîte de dialogue n'a pas de en-tête, mais il est très, très probable que ce soit le cas - les boîtes de dialogue avec un en-tête sont un modèle assez courant. Il y aura absolument une zone de contenu ici avec un contenu complètement aléatoire - du simple texte de confirmation aux formulaires en passant par les expériences interactives et les très longs textes défilants "termes et conditions" que personne ne lit.

Enfin, la taille. La boîte de dialogue dans la conception est minuscule, juste une boîte de dialogue de confirmation. Les formulaires volumineux ou les textes longs n'y trouveront pas leur place. Ainsi, compte tenu des informations que nous avons recueillies à l'étape 2, il est assez prudent de supposer que la taille de la boîte de dialogue devra être modifiée. À l'heure actuelle, étant donné que les concepteurs ont probablement des directives de conception, nous pouvons supposer que nous aurons trois variantes de la boîte de dialogue : "petit", "moyen" et "grand".

Tout cela signifie que nous devons avoir des accessoires sur ModalDialog : le pied de page et l'en-tête ne seront que des accessoires normaux qui acceptent ReactNode, la taille ne sera qu'une union de chaînes et la zone de contenu, en tant que partie principale, ira dans enfants :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

Nous contrôlerons la taille de la boîte de dialogue avec un nom de classe supplémentaire provenant des accessoires. Dans la vraie vie, cela dépendra fortement de la solution de style utilisée dans le dépôt.

Cependant, dans cette variante, le dialogue est tout simplement trop flexible : à peu près tout peut aller partout. Dans le pied de page, par exemple, la plupart du temps, on peut s’attendre à juste un bouton ou deux, rien de plus. Et ces boutons devraient être disposés de manière cohérente partout sur le site Web. Nous avons besoin d'un wrapper qui les aligne :

.backdrop {
  background: rgba(0, 0, 0, 0.3);
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

Idem avec le contenu - à tout le moins, il aurait besoin d'un peu de remplissage autour et d'une capacité de défilement. Et l'en-tête peut nécessiter certains styles pour le texte. La mise en page se transforme donc en ceci :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

Mais malheureusement, nous ne pouvons pas garantir cela. Il est fort probable qu'à un moment donné, quelqu'un veuille avoir quelque chose de plus dans le pied de page que des boutons. Ou certaines boîtes de dialogue devraient avoir un en-tête sur un arrière-plan vendu. Ou parfois, le contenu n'aura pas besoin de remplissages.

Ce à quoi je veux en venir ici, c'est que nous aurions besoin d'être en mesure de styliser la partie en-tête/contenu/pied de page un jour. Et probablement plus tôt que prévu.

Nous pourrions, bien sûr, simplement transmettre cette configuration avec des accessoires et avoir quelque chose comme les accessoires headerClassName, contentClassName et footerClassName. Et dans certains cas, ça pourrait aller, en fait. Mais pour quelque chose comme le joli dialogue pour la belle refonte, nous pourrions faire mieux.

Une manière très intéressante de résoudre ce problème consiste à extraire notre en-tête/contenu/pied de page dans des composants qui leur sont propres, comme ceci :

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

et rétablissez le code ModalDialog au code sans les wrappers :

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

De cette façon, dans l'application parent, si je souhaite avoir la conception par défaut pour les parties de dialogue, j'utiliserais ces minuscules composants :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

Et si je voulais avoir quelque chose de complètement personnalisé, j'implémenterais un nouveau composant avec ses propres styles personnalisés sans jouer avec le ModalDialog lui-même :

.backdrop {
  background: rgba(0, 0, 0, 0.3);
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

D'ailleurs, je n'ai même plus besoin des accessoires d'en-tête et de pied de page. Je peux simplement transmettre DialogHeader et DialogFooter aux enfants, simplifier encore plus ModalDialog et avoir une API encore plus agréable avec le même niveau de flexibilité tout en ayant un design cohérent partout.

Le composant parent ressemblera alors à ceci :

.dialog {
  position: fixed;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
}

Et l'API de la boîte de dialogue ressemblera à ceci :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

J'en suis plutôt content jusqu'à présent. Il est suffisamment flexible pour s'étendre de toutes les manières nécessaires à la conception, mais il est également suffisamment clair et raisonnable pour implémenter facilement une interface utilisateur cohérente dans l'ensemble de l'application.

Voici l'exemple en direct avec lequel jouer :

Étape 4 : performances et rendus

Maintenant que l'API du Modal est dans un état assez correct, il est temps d'aborder le pistolet à pied évident que j'ai implémenté. Si vous avez lu suffisamment de mes articles, vous avez probablement crié fort : "Qu'est-ce que tu fais ??? Re-rendus !!" pendant les dix dernières minutes ? Et bien sûr, vous avez raison :

const ModalDialog = ({ onClose }) => {
  return (
    <>
      <div className="backdrop" onClick={onClose}></div>
      <div className="dialog">
        <button className="close-button" onClick={onClose}>
          Close
        </button>
      </div>
    </>
  );
};

Le composant Page ici a un état. Chaque fois que le modal est ouvert ou fermé, l'état changera et cela provoquera un nouveau rendu de l'ensemble du composant et de tout ce qu'il contient. Bien que oui, "l'optimisation prématurée est la racine de tous les maux", et oui, n'optimisez pas les performances avant de les mesurer, dans ce cas, nous pouvons ignorer en toute sécurité les idées reçues.

Pour deux raisons. Tout d’abord, je sais pertinemment qu’il y aura de nombreux modaux dispersés dans l’application. Il ne s’agit pas d’une fonctionnalité cachée ponctuelle que personne n’utilisera. Ainsi, les chances que quelqu'un place un état quelque part là où il ne devrait pas être avec une API comme celle-ci sont assez élevées. Et deuxièmement, il ne faut pas beaucoup de temps et d'efforts pour éviter que le problème des nouveaux rendus ne se produise. Juste 1 minute d'effort, et nous n'aurons pas du tout besoin de penser à la performance ici.

Tout ce que nous avons à faire est d'encapsuler l'état et d'introduire l'idée d'un « composant non contrôlé » :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

Là où BaseModalDialog est exactement la même boîte de dialogue que nous avions auparavant, je l'ai simplement renommée.

Et puis transmettez un composant censé déclencher la boîte de dialogue comme accessoire de déclenchement :

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

Le composant Page ressemblera alors à ceci :

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

Plus d'état dans la page, plus de rendus potentiellement dangereux.

Une API comme celle-ci devrait couvrir 95 % des cas d'utilisation puisque, la plupart du temps, un utilisateur devrait cliquer sur quelque chose pour que la boîte de dialogue apparaisse. Dans de rares situations où une boîte de dialogue doit apparaître indépendamment, par exemple sur un raccourci ou dans le cadre de l'intégration, je peux toujours utiliser BaseModalDialog et gérer l'état manuellement.

Étape 5 : gérer les cas extrêmes et l’accessibilité

L'API du composant ModalDialog est assez solide du point de vue de React, mais le travail est loin d'être terminé. Compte tenu des éléments indispensables que j'ai rassemblés à l'étape 2, je dois encore résoudre quelques problèmes supplémentaires.

Problème 1 : J'enveloppe le déclencheur dans une étendue supplémentaire - dans certains cas, cela pourrait casser la mise en page d'une page. Je dois me débarrasser de l'emballage d'une manière ou d'une autre.

Problème 2 : Si je rends la boîte de dialogue à l'intérieur d'un élément qui crée un nouveau contexte d'empilement, le modal apparaîtra sous certains éléments. Je dois le restituer dans un portail, pas directement dans la mise en page comme je le fais maintenant.

Problème 3 : L'accès au clavier est plutôt mauvais pour le moment. Lorsqu'une boîte de dialogue modale correctement implémentée s'ouvre, le focus doit passer à l'intérieur. Lorsqu'il est fermé, le focus doit revenir sur l'élément qui a déclenché la boîte de dialogue. Lorsque la boîte de dialogue est ouverte, le focus doit être "piégé" à l'intérieur et les éléments à l'extérieur ne doivent pas pouvoir être focalisés. Appuyer sur le bouton ESC devrait fermer la boîte de dialogue. Rien de tout cela n’est mis en œuvre pour le moment.

Les problèmes 1 et 2 sont légèrement ennuyeux mais peuvent être résolus relativement rapidement. Le problème 3, cependant, est très pénible à résoudre manuellement. De plus, c'est sûrement un problème résolu - chaque dialogue, partout dans le monde, aurait besoin de cette fonctionnalité.

La combinaison de « une douleur énorme à faire par moi-même » « ressemble sûrement à un problème résolu » est l'endroit où je chercherais une bibliothèque existante.

Compte tenu de tout le travail préalable que j'ai déjà effectué, choisir le bon est maintenant facile.

Je pourrais opter pour n'importe quelle bibliothèque de composants d'interface utilisateur existante comme Ant Design ou Material UI et utiliser une boîte de dialogue à partir de là. Mais si la refonte ne les utilise pas, ajuster leurs conceptions à celles dont j'ai besoin apportera plus de douleur qu'elles n'en résoudront. C'est donc un NON instantané pour cette affaire.

Je pourrais utiliser l'une des bibliothèques d'interface utilisateur "sans tête" comme Radix ou React Aria. Ceux-ci implémentent les fonctionnalités telles que l'état et le déclencheur ainsi que toute l'accessibilité, mais laissent la conception au consommateur. En regardant leur API, je devrais vérifier qu'ils me permettent de contrôler l'état de la boîte de dialogue si j'en ai vraiment besoin pour les cas où je souhaite déclencher la boîte de dialogue manuellement (c'est ce qu'ils font).

Si, pour une raison quelconque, je ne peux pas utiliser les bibliothèques sans tête, j'essaierais au moins d'utiliser une bibliothèque qui gère la fonctionnalité de piège de focus.

Pour le bien de l'article, supposons que je puisse apporter n'importe quelle bibliothèque de mon choix. Dans ce cas, j'opterai pour Radix - il est très simple à utiliser et l'API de la boîte de dialogue ressemble beaucoup à celle que j'ai déjà implémentée, donc la refactorisation devrait être un jeu d'enfant.

Il faudrait changer un peu l'API de la boîte de dialogue elle-même :

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

C'est à peu près la même chose qu'avant. Seulement, au lieu de divs partout, j'utilise des primitives Radix.

L'utilisation incontrôlée des boîtes de dialogue ne change pas du tout :

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

Et la boîte de dialogue contrôlée change légèrement - je devrais lui transmettre des accessoires au lieu d'un rendu conditionnel :

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

Découvrez l'exemple ci-dessous et essayez d'utiliser le clavier pour naviguer. Tout fonctionne comme j'en ai besoin, n'est-ce pas cool ?

En bonus, Radix gère également le problème du portail et n'encapsule pas les déclencheurs dans un laps de temps. Je n'ai plus de cas extrêmes à résoudre, je peux donc passer à la dernière étape.

Étape 6 : polissage final

La fonctionnalité n'est toujours pas terminée ! ? La boîte de dialogue semble assez solide maintenant, donc je ne vais rien changer de majeur dans sa mise en œuvre à ce stade. Mais il lui faut encore quelques éléments pour être considéré comme un dialogue "parfait" pour le cas d'utilisation que je résout.

One : la toute première chose que les designers me demanderont de faire, s'ils ne l'ont pas encore fait, est d'ajouter une animation subtile à l'ouverture de la boîte de dialogue. Il faudrait l'anticiper et se rappeler comment faire des animations dans React.

Deux : je devrais ajouter max-width et max-height à la boîte de dialogue pour que sur les petits écrans, elle ait toujours l'air décente. Et pensez à quoi cela ressemblerait sur de très grands écrans.

Trois : J'aurais besoin de parler aux concepteurs de la façon dont la boîte de dialogue doit se comporter sur mobile. Il y a de fortes chances qu'ils me demandent d'en faire un panneau coulissant qui occupe la majeure partie de l'écran, quelle que soit la taille de la boîte de dialogue.

Quatre : je devrais introduire au moins les composants DialogTitle et DialogDescription - Radix demandera de les utiliser à des fins d'accessibilité.

Cinq : Tests ! Le dialogue est là pour rester et sera maintenu par d'autres personnes, les tests sont donc quasiment obligatoires dans ce cas.

Et probablement des tonnes d'autres petites choses que j'ai oubliées maintenant et qui reviendront plus tard. Sans parler de la mise en œuvre des conceptions réelles du contenu de la boîte de dialogue.

Quelques réflexions supplémentaires

Si vous remplacez le « dialogue » ci-dessus par « SomeNewFeature », c'est plus ou moins l'algorithme que j'utilise pour implémenter à peu près tout ce qui est nouveau.

"Augmentation" rapide de la ou des solutions → rassembler les exigences pour la fonctionnalité → la faire fonctionner → la rendre performante → la rendre complète → la rendre parfaite.

Pour quelque chose comme le dialogue lui-même, que j'ai déjà mis en œuvre des centaines de fois, je vais faire la première étape en 10 secondes dans ma tête et commencer par l'étape 2 tout de suite.

Pour quelque chose de très compliqué et inconnu, l'étape 1 peut être plus longue et impliquer l'exploration immédiate de différentes solutions et bibliothèques.

Quelque chose qui n'est pas exactement inconnu, juste une « fonctionnalité régulière que nous devons faire », pourrait sauter l'étape 1 car il n'y a peut-être rien à explorer.

Très souvent, surtout dans les environnements « agiles », il s'agira plus d'une spirale que d'une ligne droite, où les exigences sont fournies progressivement et changent souvent, et nous revenons régulièrement aux deux premières étapes.

---

J'espère que ce type d'article vous a été utile ! ?? Faites-moi savoir si vous souhaitez avoir plus de contenu comme celui-ci ou si vous préférez les trucs habituels sur « comment les choses fonctionnent ».

Et j'ai hâte d'entendre en quoi ce processus est différent dans votre tête ?

---

Publié à l'origine sur https://www.developerway.com. Le site Web a plus d'articles comme celui-ci ?

Jetez un œil au livre Advanced React pour faire passer vos connaissances sur React au niveau supérieur.

Abonnez-vous à la newsletter, connectez-vous sur LinkedIn ou suivez-nous sur Twitter pour être averti dès la sortie du prochain article.

---

Et d'ailleurs, une dernière chose : si vous démarrez bientôt un nouveau projet et que vous n'avez pas de designer ni le temps de peaufiner l'expérience de conception comme décrit - j'ai récemment passé des heures et des heures (et des heures) à mettre en œuvre un nouveau bibliothèque de composants d'interface utilisateur pour ce cas. Il comporte des composants copiables et des modèles communs, Radix et Tailwind, un mode sombre, une accessibilité et une prise en charge mobile prête à l'emploi. Y compris la boîte de dialogue modale parfaite ci-dessus ! ?

Essayez : https://www.buckets-ui.com/

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!