Tutoriel React : composants, crochets et performances

Comme indiqué dans la première partie de notre tutoriel React, démarrer avec React est relativement facile. Commencez par utiliser Create React App (CRA), lancez un nouveau projet et commencez à développer. Malheureusement, avec le temps, vous pourriez vous retrouver dans une situation où votre code deviendra plutôt difficile à maintenir, surtout si vous débutez avec React. Les composants peuvent devenir inutilement volumineux ou vous pouvez vous retrouver avec des éléments qui pourraient être des composants mais qui ne le sont pas, vous pouvez donc finir par écrire du code répétitif ici et là.

C'est là que vous devriez vraiment commencer votre parcours React, en commençant à penser aux solutions de développement React.

Chaque fois que vous approchez d'une nouvelle application, d'un nouveau design que vous devez transformer en une application React plus tard, essayez d'abord de décider quels composants seront dans votre croquis, comment vous pouvez séparer le croquis pour les rendre plus faciles à gérer, et quels éléments sont répétitif (ou leur comportement, du moins). Essayez d'éviter d'ajouter du code qui pourrait être "utile dans le futur" - cela pourrait être tentant, mais ce futur pourrait ne jamais venir et vous garderez cette fonction/composant générique supplémentaire qui a beaucoup d'options configurables.

De plus, si un composant est plus long que, disons, 2-3 de hauteur de fenêtre, il vaut peut-être la peine de le séparer (si possible) - car il sera plus facile de le lire plus tard.

Composants contrôlés ou non contrôlés dans React

Dans la plupart des applications, il y a un besoin d'entrée et une certaine forme d'interaction avec les utilisateurs, leur permettant de taper quelque chose, de télécharger un fichier, de sélectionner un champ, etc. React traite l'interaction de l'utilisateur de deux manières distinctes : les composants contrôlés et non contrôlés .

La valeur des composants contrôlés, comme leur nom l'indique, est contrôlée par React en fournissant une valeur à l'élément qui interagit avec l'utilisateur, tandis que les éléments non contrôlés n'obtiennent pas de propriété de valeur. Grâce à cela, nous avons une seule source de vérité qui se trouve être l'état React, il n'y a donc pas de décalage entre ce que nous voyons à l'écran et ce que nous avons actuellement dans notre état. Le développeur doit passer une fonction qui répondra à l'interaction de l'utilisateur avec un formulaire, ce qui changera son état.

 class ControlledInput extends React.Component { state = { value: "" }; onChange = (e) => this.setState({ value: e.target.value }); render() { return ( <input value={this.state.value} onChange={this.onChange}/> ); } }

Dans les composants React non contrôlés, nous ne nous soucions pas de la façon dont la valeur change, mais si nous voulons connaître la valeur exacte, nous y accédons simplement via ref.

 class UncontrolledInput extends React.Component { input = React.createRef(); getValue = () => { console.log(this.input.current.value); }; render() { return ( <input ref={this.input}/> ); } }

Alors, qui doit être utilisé quand? Je dirais que les composants contrôlés sont la voie à suivre dans la plupart des cas, mais il y a quelques exceptions. Par exemple, un cas où vous devez utiliser des composants non contrôlés dans React est l'entrée du type file , car sa valeur est en lecture seule et ne peut pas être définie par programme (une interaction de l'utilisateur est requise). De plus, je trouve les composants contrôlés plus faciles à lire et plus faciles à utiliser. La validation des composants contrôlés est basée sur le rendu, l'état peut être modifié et nous pouvons facilement indiquer qu'il y a quelque chose qui ne va pas avec l'entrée (par exemple, le format ou le fait d'être vide).

Réfs

Nous avons déjà mentionné refs , qui est une fonctionnalité spéciale qui était disponible dans les composants de classe jusqu'à l'apparition des crochets dans la version 16.8.

Les références peuvent donner au développeur l'accès à un composant React ou à un élément DOM (selon le type auquel nous attachons la référence) via une référence. Il est considéré comme une bonne pratique d'essayer de les éviter et de les utiliser uniquement dans des scénarios indispensables, car ils rendent le code un peu plus difficile à lire et interrompent le flux de données de haut en bas. Pourtant, il y a des cas où ils sont nécessaires, en particulier sur les éléments DOM (par exemple, changer de focus par programme). Lors de l'attachement à un élément de composant React, vous pouvez librement utiliser des méthodes à partir de ce composant auquel vous faites référence. Néanmoins, cette pratique doit être évitée car il existe de meilleures façons de la gérer (par exemple, lever l'état et déplacer les fonctions vers les composants parents).

Les références ont également trois manières différentes de les réaliser :

• Utilisation d'un littéral de chaîne (hérité et à éviter),
• À l'aide d'une fonction de rappel définie dans l'attribut ref,
• En créant ref en tant que React.createRef() et en le liant à une propriété de classe et en y accédant par son intermédiaire (sachez que les références seront disponibles à partir du cycle de vie componentDidMount).

Enfin, il y a des cas où les références ne sont pas transmises et des moments où vous souhaitez accéder à un élément de référence plus profond à partir du composant actuel (par exemple, vous avez un composant <Button> qui a un élément DOM <input> intérieur et en ce moment vous sont dans un composant <Row> , et à partir du composant de ligne auquel vous voulez avoir accès pour entrer la fonction de focus DOM. C'est là que vous utiliseriez forwardRef ).

Un cas où la référence n'est pas transmise est lorsqu'un composant d'ordre supérieur est utilisé sur un composant - la raison est tout à fait compréhensible car ref n'est PAS un prop (similaire à key ) donc il n'est pas transmis donc il sera faire référence au HOC au lieu que le composant soit enveloppé par celui-ci. Dans un tel cas, nous pouvons utiliser React.forwardRef qui prend des props et des refs comme arguments, qui peuvent ensuite être assignés à prop et transmis au composant auquel nous voulons accéder.

 function withNewReference(Component) { class Hoc extends React.Component { render() { const {forwardedRef, ...props} = this.props; return <Component ref={forwardedRef} {...props}/>; } } return React.forwardRef((props, ref) => { return <Hoc {...props} forwardedRef={ref} />; }); }

Limites d'erreur

Plus les choses deviennent complexes, plus la probabilité que quelque chose tourne mal est élevée. C'est pourquoi les limites d'erreur font partie de React. Alors comment fonctionnent-ils ?

Si quelque chose ne va pas et qu'il n'y a pas de limite d'erreur en tant que parent, cela entraînera l'échec de toute l'application React. Il est préférable de ne pas afficher d'informations plutôt que d'induire les utilisateurs en erreur et d'afficher des informations erronées, mais cela ne signifie pas nécessairement que vous devez planter toute l'application et afficher un écran blanc. Avec les limites d'erreur, vous disposez d'un degré de flexibilité supplémentaire que vous pouvez utiliser. Vous pouvez soit en utiliser un dans toute l'application et afficher un message d'erreur, soit l'utiliser dans certains widgets et simplement ne pas les afficher, soit afficher une petite quantité d'informations à la place de ces widgets.

N'oubliez pas qu'il ne s'agit que de problèmes de code déclaratif plutôt que de code impératif que vous écrivez pour gérer certains événements ou appels. Pour ceux-ci, vous devez toujours utiliser l'approche habituelle try/catch .

Les limites d'erreur sont également un endroit où vous pouvez envoyer des informations au journal d' erreurs que vous utilisez (dans la méthode de cycle de vie componentDidCatch ).

 class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { logToErrorLogger(error, info); } render() { if (this.state.hasError) { return <div>Help, something went wrong.</div>; } return this.props.children; } }

Composants d'ordre supérieur

Les composants d'ordre supérieur (HOC) sont souvent mentionnés dans React et constituent un modèle très populaire, que vous utiliserez probablement (ou que vous avez déjà utilisé). Si vous êtes familier avec les HOC, vous avez probablement vu withNavigation, connect, withRouter dans de nombreuses bibliothèques.

Les HOC ne sont que des fonctions qui prennent un composant comme argument et renverront un nouveau composant avec des capacités étendues par rapport à celui sans le wrapper HOC. Grâce à cela, vous pouvez obtenir des fonctions facilement extensibles qui pourraient améliorer vos composants (par exemple, l'accès à la navigation). Les HOC peuvent également prendre quelques formes appelées en fonction de ce que nous avons, le seul argument toujours requis étant un composant, mais il peut prendre des arguments supplémentaires - certaines options, ou comme dans connect , vous invoquez d'abord une fonction avec des configurations qui renvoient plus tard une fonction qui prend un composant en argument et renvoie HOC.

Il y a quelques choses que vous pourriez ajouter et que vous devriez éviter :

• Ajoutez un nom d'affichage pour votre fonction wrapper HOC (afin que vous sachiez qu'il s'agit en fait d'un HOC en modifiant le nom d'affichage de votre composant HOC).
• N'utilisez pas HOC dans une méthode de rendu - vous devriez déjà utiliser un composant amélioré à l'intérieur de celle-ci, au lieu de créer un nouveau composant HOC à cause de le remonter tout le temps et de perdre son état actuel.
• Les méthodes statiques ne sont pas copiées, donc si vous voulez avoir des méthodes statiques à l'intérieur de votre HOC nouvellement créé, vous devez les copier vous-même.
• Les références mentionnées ne sont pas transmises, utilisez React.forwardRef comme mentionné précédemment pour résoudre ces problèmes.

 export function importantHoc() { return (Component) => class extends React.Component { importantFunction = () => { console.log("Very Important Function"); }; render() { return ( <Component {...this.props} importantFunction={this.importantFunction} /> ); } }; }

Coiffant

Le style n'est pas nécessairement lié à React lui-même, mais il convient de le mentionner pour un certain nombre de raisons.

Tout d'abord, les styles CSS/inline habituels s'appliquent ici normalement et vous pouvez simplement ajouter des noms de classe à partir de CSS dans l'attribut className, et cela fonctionnera correctement. Le style en ligne est un peu différent du style HTML normal. La chaîne n'est pas transmise avec des styles mais plutôt des objets avec des valeurs correctes pour chacun. Les attributs de style sont également en camelCased, donc border-radius devient borderRadius et ainsi de suite.

React semble avoir popularisé quelques solutions qui sont devenues courantes non seulement dans React, comme les modules CSS qui ont été récemment intégrés dans CRA, où vous pouvez simplement importer name.modules.css et utiliser ses classes comme des propriétés pour styliser votre composant (certains IDE , par exemple, WebStorm, ont également Autocomplete pour cela, qui vous indique quels noms sont disponibles).

Une autre solution également populaire dans React est CSS-in-JS (par exemple, la bibliothèque d' emotion ). Juste pour souligner à nouveau, les modules CSS et l'émotion (ou CSS-in-JS en général) ne se limitent pas à React.

Crochets dans React

Les crochets sont probablement l'ajout le plus attendu à React depuis la réécriture. Le produit est-il à la hauteur du battage médiatique? De mon point de vue, oui, car ils sont vraiment une fonctionnalité intéressante. Ce sont essentiellement des fonctions qui ouvrent de nouvelles opportunités, telles que :

• Permet la suppression d'un grand nombre de composants de class que nous n'utilisions que parce que nous ne pouvions pas avoir, par exemple, un état local ou une référence, de sorte que le code d'un composant semble plus facile à lire.
• Vous permet d'utiliser moins de code pour le même effet.
• Rend les fonctions beaucoup plus faciles à penser et à tester, par exemple en utilisant la bibliothèque de tests de réaction.
• Peut également prendre des paramètres, et le résultat de l'un peut être facilement utilisé par un autre crochet (par exemple, setState de useState dans useEffect ).
• Minifie bien mieux que les classes, qui ont tendance à être un peu plus problématiques pour les minificateurs.
• Peut supprimer les HOC et rendre les modèles d'accessoires dans votre application qui ont introduit de nouveaux problèmes bien qu'ils aient été conçus pour en résoudre d'autres.
• Capable d'être construit sur mesure par n'importe quel développeur React qualifié.

Il y a peu de hooks React qui sont inclus par défaut. Les trois de base sont useState , useEffect et useContext . Il y en a aussi plusieurs supplémentaires, par exemple useRef et useMemo , mais pour l'instant, nous allons nous concentrer sur les bases.

Jetons un coup d'œil à useState et utilisons-le pour créer un exemple de compteur simple. Comment ça marche? Eh bien, en gros, toute la construction est vraiment simple et ressemble à :

 export function Counter() { const [counter, setCounter] = React.useState(0); return ( <div> {counter} <button onClick={() => setCounter(counter + 1)}>+</button> </div> ); };

Il est invoqué avec initialState (valeur) et renvoie un tableau avec deux éléments. Grâce à l'affectation par déstructuration de tableaux, nous pouvons affecter immédiatement les variables à ces éléments. Le premier est toujours le dernier état après les mises à jour, tandis que l'autre est une fonction que nous utiliserons pour mettre à jour la valeur. Cela semble plutôt facile, n'est-ce pas ?

De plus, du fait que ces composants étaient autrefois appelés composants fonctionnels sans état, un tel nom n'est plus approprié, car ils peuvent avoir un état comme indiqué ci-dessus. Par conséquent, les noms des composants de classe et des composants de fonction semblent être plus conformes à ce qu'ils font réellement, du moins à partir de 16.8.0.

La fonction update (dans notre cas setCounter ), peut également être utilisée comme une fonction qui prendra la valeur précédente en argument sous la forme suivante :

 <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button>

Cependant, contrairement au composant de classe this.setState qui effectuait une fusion superficielle, la définition de la fonction ( setCounter dans notre cas) remplace l'état entier à la place.

De plus, initialState peut également être une fonction, pas seulement une valeur simple. Cela a ses propres avantages, car cette fonction ne sera exécutée que lors du rendu initial du composant et après cela, elle ne sera plus invoquée.

 const [counter, setCounter] = useState(() => calculateComplexInitialValue());

Enfin, si nous allons utiliser setCounter avec exactement la même valeur que nous avions au même moment dans l'état actuel ( counter ), alors le composant ne sera pas restitué.

D'autre part, useEffect consiste à ajouter des effets secondaires à notre composant fonctionnel, qu'il s'agisse d'abonnements, d'appels d'API, de minuteries ou à peu près de tout ce que nous pouvons trouver utile. Toute fonction que nous passerons à useEffect sera exécutée après le rendu, et ce, après chaque rendu, à moins que nous n'ajoutions une limitation concernant les modifications de propriétés à réexécuter en tant que deuxième argument de la fonction. Si nous voulons l'exécuter uniquement lors du montage et nettoyer lors du démontage, il nous suffit de lui transmettre un tableau vide.

 const fetchApi = async () => { const value = await fetch("https://jsonplaceholder.typicode.com/todos/1"); console.log(await value.json()); }; export function Counter() { const [counter, setCounter] = useState(0); useEffect(() => { fetchApi(); }, []); return ( <div> {counter} <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button> </div> ); };

Le code ci-dessus ne sera exécuté qu'une seule fois en raison d'un tableau vide comme deuxième argument. Fondamentalement, c'est quelque chose comme componentDidMount dans ce cas, mais il se déclenche un peu plus tard. Si vous souhaitez avoir un crochet similaire appelé avant la peinture du navigateur, utilisez useLayoutEffect , mais ces mises à jour seront appliquées de manière synchrone, contrairement à useEffect .

useContext semble être le plus facile à comprendre, car on indique à quel contexte nous voulons accéder (un objet qui a été renvoyé par la fonction createContext ) et en retour, il nous fournit la valeur de ce contexte.

 const context = useContext(Context);

Enfin, pour écrire votre propre crochet, vous pouvez simplement écrire quelque chose comme ceci :

 function useWindowWidth() { let [windowWidth, setWindowWidth] = useState(window.innerWidth); function handleResize() { setWindowWidth(window.innerWidth); } useEffect(() => { window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize); }, []); return windowWidth; }

Fondamentalement, nous utilisons le crochet useState pour lequel nous attribuons comme valeur initiale la largeur de la fenêtre. Ensuite, dans useEffect, nous ajoutons un écouteur qui déclenchera handleResize à chaque redimensionnement de fenêtre. Nous clarifions également après le démontage du composant (regardez le retour dans useEffect ). Facile?

Remarque : Le mot utilisé dans tous les crochets est important. Il est utilisé car il permet à React de vérifier si vous ne faites pas quelque chose de mal, par exemple, appelez des hooks à partir de fonctions JS régulières.

Vérification des types

React avait ses propres vérifications d'accessoires, avant que Flow et TypeScript ne soient une option.

PropTypes vérifie si les propriétés (props) qui sont reçues par un composant React et vérifie si elles sont conformes à ce que nous avons. Chaque fois qu'une situation différente se produit (par exemple, un objet au lieu d'un tableau), nous recevrons un avertissement dans la console. Il est important de noter que les PropTypes ne sont vérifiés qu'en mode développement en raison de leur impact sur les performances et de l'avertissement de console susmentionné.

Depuis React 15.5, les PropTypes se trouvent dans un package différent qui doit être installé séparément. Ils sont déclarés avec des propriétés dans une propriété statique appelée propTypes (surprise), en les combinant avec defaultProps qui sont utilisés si les propriétés sont indéfinies ( undefined est le seul cas). Les DefaultProps ne sont pas liés aux PropTypes, mais ils peuvent résoudre certains avertissements pouvant apparaître en raison des PropTypes.

Les deux autres options sont Flow et TypeScript, et elles sont beaucoup plus populaires de nos jours (surtout TypeScript).

• TypeScript est un sur-ensemble typé de JavaScript, développé par Microsoft, qui peut vérifier les erreurs avant même qu'une application ne soit en cours d'exécution et fournit une fonctionnalité de saisie semi-automatique supérieure pour le développement. Cela améliore également considérablement le refactoring. Grâce au support Microsoft, qui possède une vaste expérience des langages typés, il s'agit également d'un choix plutôt sûr.
• Flow n'est pas un langage, contrairement à TypeScript. Il s'agit d'un vérificateur de type statique pour JavaScript, il s'apparente donc davantage à un outil que vous incluez dans JavaScript qu'à un langage. L'idée derrière Flow est assez similaire à ce que propose TypeScript. Il vous permet d'ajouter des types afin qu'il soit moins susceptible d'avoir des bogues avant d'exécuter le code. Tout comme TypeScript, Flow est désormais pris en charge dans CRA (Create React App) dès le départ.

Personnellement, je trouve TypeScript plus rapide (pratiquement instantané), notamment en autocomplétion, qui semble un peu plus lent avec Flow. Il convient de noter que les IDE tels que WebStorm, que j'utilise personnellement, utilisent une CLI pour l'intégration avec Flow. Cependant, il semble encore plus facile d'intégrer une utilisation facultative dans les fichiers, où vous ajoutez simplement // @flow au début du fichier pour lancer la vérification du type. De plus, d'après ce que je peux dire, il semble que TypeScript ait finalement gagné la bataille contre Flow - il est beaucoup plus populaire maintenant, et certaines des bibliothèques les plus populaires sont refactorisées de Flow à TypeScript.

Il existe quelques autres options, également mentionnées dans la documentation officielle, telles que Reason (développé par Facebook et qui gagne en popularité dans la communauté React), Kotlin (un langage développé par JetBrains) et plus encore.

De toute évidence, pour les développeurs front-end, l'approche la plus simple serait de se lancer et de commencer à utiliser Flow et TypeScript, plutôt que de passer à Kotlin ou F #. Cependant, pour les développeurs back-end qui passent au front-end, ceux-ci pourraient en fait être plus faciles à démarrer.

Performances de production et de réaction

Le changement le plus basique et le plus évident que vous devez faire pour le mode de production est de passer en "production" pour DefinePlugin et d'ajouter UglifyJsPlugin dans le cas de Webpack. Dans le cas de CRA, c'est aussi simple que d'utiliser npm run build (qui exécutera react-scripts build ). Sachez que Webpack et CRA ne sont pas les seules options, car vous pouvez utiliser d'autres outils de construction comme Brunch. Ceci est généralement couvert dans la documentation officielle, qu'il s'agisse de la documentation officielle de React ou de la documentation d'un outil spécifique. Pour vous assurer que le mode est correctement défini, vous pouvez utiliser React Developer Tools, qui vous donnera une indication du type de build que vous utilisez (production ou développement). Les étapes susmentionnées feront fonctionner votre application sans vérifications ni avertissements provenant de React et le bundle lui-même sera également minimisé.

Il y a quelques autres choses que vous pouvez faire pour votre application React. Que faites-vous avec le fichier JS qui est construit ? Vous pouvez commencer avec juste "bundle.js" si la taille est relativement petite, ou peut-être faire quelque chose comme "vendeur + bundle" ou peut-être "vendeur + plus petite partie requise + importer des choses quand elles sont nécessaires". Ceci est utile lorsque vous avez affaire à une très grosse application et que vous n'avez pas besoin de tout importer au tout début. Sachez que le fait de regrouper du code JavaScript dans le bundle principal qui n'est même pas utilisé augmentera simplement la taille du bundle et ralentira le chargement de l'application au tout début.

Les bundles de fournisseurs peuvent être utiles si vous prévoyez de geler les versions des bibliothèques en réalisant qu'elles pourraient ne pas changer pendant longtemps (voire jamais). De plus, les fichiers plus volumineux sont meilleurs pour le gzipping, de sorte que l'avantage que vous obtenez de la séparation peut parfois ne pas en valoir la peine. Cela dépend de la taille du fichier et parfois vous devrez simplement l'essayer vous-même.

Fractionnement de code

Le fractionnement de code peut apparaître de plusieurs manières que ce qui est suggéré ici, mais concentrons-nous sur ce dont nous disposons dans CRA et React lui-même. Fondamentalement, afin de diviser le code en différents morceaux, nous pouvons utiliser import() qui fonctionne grâce à Webpack (l' import elle-même est une proposition à l'étape 3 pour le moment, elle ne fait donc pas encore partie de la norme de langage). Chaque fois que Webpack verra import , il saura qu'il doit commencer à diviser le code à ce stade et ne peut pas l'inclure dans le bundle principal (le code qu'il contient dans l'importation).

Nous pouvons maintenant le connecter avec React.lazy() qui nécessite import() avec un chemin de fichier contenant le composant qui doit être rendu à cet endroit. Ensuite, nous pouvons utiliser React.suspense() qui affichera un composant différent à cet endroit jusqu'à ce que le composant importé soit chargé. On pourrait se demander; si nous importons un seul composant, pourquoi en aurions-nous besoin ?

Ce n'est pas tout à fait le cas, car React.lazy() affichera le composant que nous import() , mais import() pourrait récupérer un plus gros morceau que ce composant unique. Par exemple, ce composant particulier peut avoir d'autres bibliothèques en remorque, plus de code, etc., donc un fichier n'est pas nécessaire - il peut s'agir de beaucoup plus de fichiers regroupés. Enfin, nous pouvons envelopper tout cela dans ErrorBoundary (vous pouvez trouver le code dans notre section sur les limites d'erreur) qui servira de solution de repli si quelque chose échoue avec le composant que nous voulions importer (par exemple, s'il y a une erreur réseau).

 import ErrorBoundary from './ErrorBoundary'; const ComponentOne = React.lazy(() => import('./ComponentOne')); function MyComponent() { return ( <ErrorBoundary> <React.Suspense fallback={<div>Loading...</div>}> <ComponentOne/> </React.Suspense> </ErrorBoundary> ); }

Ceci est un exemple basique, mais vous pouvez évidemment faire plus. Vous pouvez utiliser import et React.lazy pour le fractionnement dynamique des routes (par exemple, administrateur vs utilisateur régulier, ou simplement de très grands chemins qui apportent beaucoup). Sachez que React.lazy ne prend en charge que les exportations par défaut pour le moment et ne prend pas en charge le rendu côté serveur.

Réagir aux performances du code

En ce qui concerne les performances, si votre application React est lente, deux outils peuvent vous aider à résoudre le problème.

Le premier est Chrome Performance Tab, qui vous dira ce qui se passe avec chaque composant (par exemple, montage, mise à jour). Grâce à cela, vous devriez être en mesure d'identifier quel composant présente des problèmes de performances, puis de l'optimiser.

L'autre option consiste à utiliser DevTools Profiler qui est devenu disponible dans React 16.5+, et avec la coopération de shouldComponentUpdate (ou PureComponent, qui a été expliqué dans la première partie de ce didacticiel), nous pouvons améliorer les performances de certains composants critiques.

Évidemment, l'utilisation des meilleures pratiques de base pour le Web est optimale, comme l'anti-rebond de certains événements (par exemple, le défilement), la prudence avec les animations (en utilisant la transformation au lieu de changer la hauteur et de l'animer), etc. L'utilisation des meilleures pratiques peut être très facilement négligée, surtout si vous commencez tout juste à vous familiariser avec React.

L'état de React en 2019 et au-delà

Si nous devions discuter de l'avenir de React, personnellement, je ne serais pas trop inquiet. De mon point de vue, React n'aura aucun mal à garder son trône en 2019 et au-delà.

React a une position si forte, soutenue par une large communauté de followers, qu'il sera difficile de le détrôner. La communauté React est géniale, elle ne manque pas d'idées et l'équipe principale travaille constamment à améliorer React, en ajoutant de nouvelles fonctionnalités et en résolvant d'anciens problèmes. React est également soutenu par une énorme entreprise, mais les problèmes de licence ont disparu - il est actuellement sous licence MIT.

Oui, certaines choses devraient être modifiées ou améliorées ; par exemple, rendre React un peu plus petit (l'une des mesures mentionnées est la suppression des événements synthétiques) ou renommer className en class. Bien sûr, même ces modifications apparemment mineures pourraient entraîner des problèmes tels que la compatibilité du navigateur. Personnellement, je me demande également ce qui se passera lorsque WebComponent gagnera en popularité, car cela pourrait augmenter certaines des choses avec lesquelles React est souvent utilisé aujourd'hui. Je ne crois pas qu'ils seront un remplacement pur et simple, mais je pense qu'ils pourraient bien se compléter.

En ce qui concerne le court terme, les crochets viennent d'arriver à React. C'est probablement le plus grand changement depuis la réécriture de React, car ils ouvriront de nombreuses possibilités et amélioreront d'autres composants fonctionnels (et ils sont vraiment en train d'être mis en avant maintenant).

Enfin, comme c'est ce que j'ai fait le plus récemment, il y a React Native. Pour moi, c'est une excellente technologie qui a tellement changé au cours des deux dernières années (l'absence d'un lien natif réactif était probablement le plus gros problème pour la plupart des gens, et il y avait évidemment beaucoup de bogues). React Native est en train de réécrire son noyau, et cela devrait être fait de la même manière que la réécriture de React (tout est interne, rien ou presque ne doit être changé pour les développeurs). Rendu asynchrone, un pont plus rapide et plus léger entre natif et JavaScript, et plus encore.

Il y a beaucoup à attendre dans l'écosystème React, mais les mises à jour des hooks (et React Native si quelqu'un aime les mobiles) sont probablement les changements les plus importants que nous verrons en 2019.