• Assurez la sécurité des applications de la bonne manière! Détectez, protégez, surveillez, accélérez et plus encore…
  • Je pense qu'il est juste de dire qu'en ce qui concerne les Hooks, vous trouverez trois types de développeurs React: amour l'idée, haine l'idée, et tout simplement confus à propos de toute l'affaire.

    Si vous faites partie de ceux qui se demandent ce qu'est le bruit, cet article vous apportera un soulagement indispensable.

    Alors, prenez un café, penchez-vous en arrière et profitez-en!

    Les changements rapides et les changements tectoniques du jour au lendemain ne dérangent pas les développeurs frontaux. Ils ont compris que la résistance est vaine et se sont attachés pour apprendre une nouvelle Cadre CSS chaque année, un nouveau Framework JavaScript chaque semaine (parce que c'est à quelle vitesse ils semblent proliférer) et des réécritures complètes des applications Web personnelles et professionnelles tous les deux ans.

    Et pourtant, personne n'était préparé pour le changement gigantesque que l'équipe React de Facebook a apporté avec Hooks. Tout à coup, Développeurs React on leur disait que l'ancienne façon de créer des applications avec des classes n'était pas la meilleure idée qui soit; et qu'ils devraient maintenant adopter cette chose brillante, nouvelle et hautement capable appelée Hooks.

    Sur la question de savoir si tout le monde devrait réécrire les classes de leur application React en Hooks, l'équipe de base de React les a dissuadés, arguant que c'était trop d'effort. Mais ils vraiment pressé sur l'idée que les composants basés sur les classes passent en mode maintenance, et les Hooks sont le nouvel avenir radieux que tout le monde veut.

    Errrrrr. . . okayyyyyy. . . . .

    Cela a laissé tout le monde se gratter la tête. Les crochets avaient une surface non triviale à couvrir, le modèle mental était renversé et la courbe d'apprentissage (avec de nombreux moments de «surprise!») Était raide. Au moment de la rédaction, 18 mois après la sortie, les Hooks deviennent plus ou moins un standard dans les applications React. Les connaître est un must pour les nouveaux développeurs (comme, malheureusement, connaître les composants basés sur les classes car ils sont utilisés dans de nombreux projets récents / anciens).

    Mais la scène générale reste floue; ceux qui comprennent un peu les hameçons se sont déclarés «experts», tandis que les autres tâtonnent dans le noir. Parmi les développeurs seniors, presque tous considèrent les Hooks comme une bien meilleure solution, tandis que quelques-uns disent qu'ils ne sont qu'une arme de plus dans leur réserve.

    Le point crucial est que les vents soufflent en direction de Hooks et que vous les aimiez ou non, vous feriez votre carrière un majeur favoriser en les comprenant. Passons maintenant à comprendre deux choses de base à propos des Hooks: 1) ce qu'ils sont; et 2) pourquoi vous en avez besoin.

    Cependant, je sens que je dois souligner le flux de cet article.

    Normalement, il serait logique de s'attaquer au problème "quelle"De quelque chose de nouveau et ensuite seulement passer à"pourquoi«. Cependant, comme il s'agit d'un article pour les développeurs React confus (ou juste pour les développeurs frontaux en général), je pense qu'il est beaucoup plus important d'aborder le problème en expliquant le type de problèmes que les Hooks résolvent. Cela fait, la tension dans nos esprits sera dissoute, et nous connaîtrons la philosophie et le pragmatisme derrière Hooks. Et puis, convaincus de l'idée (ou pas, bien que cela n'aidera pas beaucoup si vous souhaitez devenir / rester développeur React), nous pouvons passer par un aperçu de ce que sont les Hooks.

    Pourquoi les React Hooks ont-ils été créés?

    Les Hooks n'ont pas été créés simplement parce que de brillants ingénieurs de Facebook devenaient agités. Vous voyez, React est quelque chose que Facebook utilise lui-même (et très fortement aussi), donc dès le premier jour, ils ont cherché à faire évoluer React dans la direction qui répond le mieux à leurs besoins (travail d'interface composable et haute performance). Après avoir écrit et maintenu des dizaines de milliers de composants, l'équipe React a décidé que les composants basés sur les classes ne fonctionnaient pas.

    Examinons diverses raisons (mises en évidence par Facebook et d'autres) qui ont incité les développeurs à n'aimer les composants basés sur les classes.

    Les classes JavaScript sont un mensonge.

    C'est ma plainte personnelle concernant la direction que prend le langage de base. JavaScript peut ressembler à un langage à accolades inspirées du C, mais c'est là que s'arrête la similitude. Mais alors, la version ES5 / ES6 du langage a cloué sur les «classes». Soudainement, le code JavaScript «moderne» a incité les développeurs d'autres langages à se sentir chez eux:

    class ShoppingCart extends BasicShoppingCart {
    	constructor(items) {
        	super(items);
            this.items = items;
        }
        
        getTotalPrice() {
        	let price = 0;
            for (let item of this.items) {
            	price += item.price;
            }
            return price;
        }
        
        // and so on
    }

    Classes, sous-classes, hiérarchies d'héritage, constructeurs, getters, setters, membres statiques (grosso modo), les extends et new mots-clés - des trucs qui donnent aux architectes de POO endurcis des orgasmes mentaux (avec tout le respect dû à leur expérience et à leurs capacités). Tout comme le fait de coller «Java» dans le nom du langage (à ses débuts, quand il s'appelait LiveScript) a fonctionné comme un brillant coup marketing, le mot-clé «classe» était peut-être censé renforcer la position et se fondre dans la foule des langages qui sont très similaires les uns aux autres (PHP, Perl, Python, Ruby, Java - vous pouvez effectuer une transition presque transparente de l'un à l'autre).

    Mais les classes sont un mensonge (du type «damné») en JavaScript. Lorsqu'un moteur JavaScript exécute du code, il n'a aucune notion de classes; ainsi, un outil comme Babel est nécessaire pour convertir des classes «modernes», «jolies» en fonctions simples. S'il y a héritage impliqué, il est converti en uniquement. type d'héritage possible en JavaScript - Héritage prototypique.

    Ainsi, lorsque nous fermons les yeux et écrivons du code basé sur les classes, nous nous mentons et affaiblissons notre position pour le jour où nos connaissances superficielles nous mordront.

    Eh bien, précise est délicat!

    Malgré la courageuse tentative de cacher le mot-clé fondamental this en JavaScript, le problème survient souvent dans les classes React (et les classes JavaScript aussi, en général). Dans plusieurs cas d'utilisation, les fonctions du composant génèrent des erreurs car elles ne sont pas liées au bon contexte à ce moment de l'exécution. Pour résoudre ce problème, vous devez bind() eux (lire précise pour plus de détails) au début du contexte React explicitement, ou utilisez les fonctions fléchées pour les rappels. Ce n'est certainement pas un facteur décisif, mais cela augmente le fardeau cognitif en ajoutant encore une autre chose dont il faut être conscient à tout moment; et bien sûr, c'est le gouffre dans lequel chaque nouveau développeur React tombe.

    Beaucoup de bruit pour quelque chose

    La réutilisation du code est un objectif commun dans développement de logiciels. Les classes peuvent promouvoir la réutilisation du code dans d'autres contextes (et langages), mais dans React, elles introduisent des problèmes de partage de code. C'était un point majeur de débat / d'intérêt dès le début dans le monde React, et la communauté a finalement développé des solutions telles que les composants d'ordre supérieur et les accessoires de rendu pour y faire face. L'idée de base est que les composants sont transmis à d'autres composants, qui «enveloppent» certaines fonctionnalités autour d'eux. Quiconque a touché au code en utilisant ces «solutions» connaît la douleur et ne veut pas le refaire (moi y compris).

    Lisez ce guide pour comprendre Comportement de rendu de réaction.

    Il vous suffit de lire la documentation officielle pour Composants d'ordre supérieur pour voir par vous-même à quel point l'idée est lourde. Dans les projets du monde réel, plusieurs morceaux de code doivent souvent être partagés, ce qui peut facilement entraîner plusieurs couches de hiérarchie d'encapsulation de composants. C'est le genre de code que même son auteur ne comprendra pas après quelques semaines! Oui, bien que la réutilisation du code ne soit pas impossible lors de l'utilisation des classes React, elle est maladroite et déroutante.

    Forage d'hélice

    Le forage des accessoires est le problème auquel vous êtes confronté (dans Vanilla React, du moins) lorsque vous avez un accessoire en haut de la hiérarchie des composants, et il doit être mis à disposition d'un composant en bas. Voici un exemple: considérez le profil utilisateur dans une application Web typique, qui est généralement affiché dans l'en-tête. Maintenant, supposons que les détails de l'utilisateur soient également nécessaires dans le composant de pied de page, peut-être pour dire quelque chose comme «Vous avez effectué 34 transactions jusqu'à présent | Obtenez des statistiques plus intéressantes ici ». Comment rendre les informations de profil disponibles dans le pied de page si vous utilisez des classes? Eh bien, certains développeurs React que je connais diraient "foutez-le!" et faites également un appel API supplémentaire dans le pied de page, mais c'est une pratique terrible.

    La seule approche qui me vient à l'esprit est également la seule option: continuer à faire passer le support de profil du composant à son composant enfant jusqu'à ce qu'il atteigne le composant de pied de page. Oui, c'est un processus fastidieux, et oui, cela rend le code difficile à lire (car dans les composants intermédiaires, vous devez continuer mentalement à ignorer l'accessoire car il n'a aucune utilité sauf simplement en descendant). Cette manipulation en chaîne descendante d'un hélice s'appelle le forage d'hélice et est un phénomène redouté dans le monde React.

    Lors de l'utilisation de classes, les développeurs de React le résoudraient en utilisant quelque chose comme Redux, mais c'est trop d'investissement initial si vous n'allez pas utiliser Redux pour tout. Avec Hooks, React a publié une fonctionnalité appelée Contexte qui a été fait sur mesure pour ce cas d'utilisation. Maintenant, Context peut également être utilisé avec des classes, mais il est difficile d'ignorer la maladresse; aussi, avec Hooks, consommer plusieurs contextes est un jeu d'enfant.

    Moins de choses à apprendre

    Cela peut sembler paradoxal et l'équipe React reconnaît l'argument. Une toute nouvelle façon d'écrire Applis de réaction sont introduits; on nous dit que nous ne devrions pas réécrire ou jeter le code existant basé sur les classes, et pourtant l'équipe React nous dit qu'il y a moins de choses à apprendre!

    «Quelqu'un vient de me tirer dessus!»

    En fait, le fait est qu'à court terme, la complexité et la confusion globales de l'écosystème React vont monter en flèche (et c'est le cas, car les nouvelles personnes apprenant React doivent apprendre les classes, les HoC, les Hooks, le contexte, Redux et de nombreuses autres bibliothèques. ainsi que leurs valises d'angle). Mais le point le plus important est que si Hooks s'avère être un concept réussi, à long terme, un grand nombre de concepts peuvent être abandonnés, nous laissant avec un petit noyau de Hooks, de composants fonctionnels et pas grand-chose d'autre. Cela ne se produit pas de sitôt (simplement à cause de la quantité de code existant basé sur les classes), mais c'est là que nous finirons par finir.

    «Mise à niveau» des composants sensibles

    Un dilemme courant dans React est de décider si un nouveau composant doit être écrit en tant que classe ou en tant que fonction. Pour minimiser la complexité, la pratique courante a été de commencer par un composant fonctionnel sans état. Ensuite, si un moment arrive où vous pensez que le composant en question doit gérer un état ou a besoin d'accéder à plus de fonctionnalités (méthodes de cycle de vie, par exemple), vous le convertissez en un composant basé sur les classes. Sauf que vous devez simplement supprimer tout le code du composant, repenser l'approche, puis écrire une version basée sur les classes. Pas amusant, oui.

    Avec Hooks, ces «mises à niveau» de composants sont plus faciles et plus fluides: un composant fonctionnel reste un composant fonctionnel même après avoir assumé de nombreuses tâches; les méthodes de cycle de vie ne figurent pas dans Hooks, bien que certaines fonctionnalités similaires soient disponibles; enfin, toute fonctionnalité commune peut être extraite dans des crochets séparés et réutilisée par d'autres composants. Avez-vous repéré la beauté dans ce cas? - tout est soit une fonction, soit un crochet (qui est aussi une fonction, mais nous pouvons faire la distinction pour des raisons de développement), et il n'y a aucune affaire de singe impliquée lorsque vous essayez de placer une cheville carrée dans un trou rond. 😀

    Donc, là nous l'avons. Les crochets ne visent pas une seule chose mais constituent un changement de paradigme majeur. C'est peu pratique, oui, mais l'expérience des développeurs qui en résulte est bien meilleure (par rapport à React avec des classes).

    Maintenant que nous avons traité du «pourquoi», tournons notre attention vers ce que sont vraiment les Hooks.

    Que sont les Hooks dans React?

    Les hameçons sont résistants et très faciles à définir en même temps. La version facile est ce que vous trouverez dans les phrases initiales de la documentation officielle: Les hooks sont un moyen d'écrire des composants React sans classes; ils vous fournissent également des moyens de «raccorder» les fonctionnalités principales de React telles que l'état, le contrôle des restitutions, etc., dans les composants fonctionnels.

    Cela n'a pas beaucoup aidé, non?!

    Parce que cela ne m'a pas aidé la première fois, je suis tombé sur Hooks. Pour comprendre ce que les crochets vraiment sont, vous devez faire une étude longue et patiente de leurs tenants et aboutissants (et ils ne manquent pas!), créer des applications en les utilisant (peut-être même reconstruire des applications antérieures), être mordu par des cas particuliers, etc.

    Mais juste pour vous en donner une «impression», voici à quoi ressemble le code avec Hooks. N'oubliez pas que tous les composants sont fonctionnels et que le code correspondant à un composant est défini à l'intérieur.

    import React, { useState } from 'react';
    
    export function Counter() {
      const [count, setCount] = useState(0);
    
      return (
        <div>
          <p>You clicked {count} times</p>
          <button onClick={() => setCount(count + 1)}>
            Click me
          </button>
        </div>
      );
    }

    Oui, c'est le même composant Counter que nous avons tous écrit des dizaines de fois en utilisant des classes! Mais vous pouvez voir à quel point les différences sont drastiques: le constructeur disparaît, l'accès et le changement d'état sont beaucoup plus simples et modulaires (vous pouvez avoir autant useState() invocations dont vous avez besoin pour gérer différents éléments d'état), et le code est plus court. Dans plusieurs cas, le code résultant est beaucoup plus court qu'un composant basé sur des classes - simplement parce que les Hooks capturent et fournissent la même fonctionnalité de manière succincte.

    Il existe plusieurs types de crochets, et useState() est juste l'un d'entre eux. Si vous êtes curieux de savoir combien il y en a et ce qu'ils font, jetez un œil au site officiel docs.

    Conclusion

    Les hameçons apportent d'énormes changements à l'écosystème React et sont là pour rester. Ils simplifient la structure des composants, l'architecture, la hiérarchie, la réutilisation du code et bien plus encore. Bien qu'il y ait quelques critiques extrêmement vocaux, l'accueil général a été très chaleureux et l'avenir semble prometteur.

    C'est l'une de ces contributions fondamentales de l'équipe React qui est susceptible d'avoir un impact sur d'autres cadres et d'influencer développement frontal fondamentalement.

    Ensuite, découvrez comment démarrer avec Livre d'histoires React.