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

C’est là que vous devriez essayer de vraiment commencer votre aventure React, en commençant à réfléchir Solutions de développement React .

Chaque fois que vous approchez d'une nouvelle application, d'un nouveau design que vous devez transformer en application React plus tard, essayez d'abord de décider quels composants seront dans votre esquisse, comment vous pouvez séparer l'esquisse pour les rendre plus faciles à gérer et quels éléments sont répétitif (ou leur comportement, au moins). Essayez d'éviter d'ajouter du code qui pourrait être «utile dans le futur» - cela pourrait être tentant, mais cet avenir pourrait ne jamais venir et vous conserverez 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 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 et non contrôlés dans React

Dans la plupart des applications, des entrées et une certaine forme d'interaction avec les utilisateurs sont nécessaires, 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: contrôlé et incontrôlé Composants.

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é value. Grâce à cela, nous avons une seule source de vérité qui se trouve être l'état React, donc il n'y a 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 ( ); } }

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 ( ); } }

Alors, qui devrait ê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 dans lequel vous devez utiliser des composants non contrôlés dans React est le file type d'entrée, 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 que les composants contrôlés sont plus faciles à lire et à 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 sont une fonctionnalité spéciale qui était disponible dans les composants de classe jusqu'à l'apparition des hooks dans 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 ref) 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 incontournables, 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 d'orientation par programme). Lors de l'attachement à un élément de composant React, vous pouvez utiliser librement 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).

sites Web qui utilisent les principes de la gestalt

Les références peuvent également être accomplies de trois manières différentes:

• Utilisation d'une chaîne littérale (héritée et doit être évitée),
• À l'aide d'une fonction de rappel qui est définie dans l'attribut ref,
• En créant ref as React.createRef() et le lier à une propriété de classe et y accéder (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 qui a un élément insideDOM et vous êtes maintenant dans un composant, et à partir de la ligne composant auquel vous voulez avoir accès pour entrer la fonction de focus DOM. C'est là que vous utiliserez forwardRef).

Un cas où la référence n'est pas transmise est lorsqu'il y a un composant d'ordre supérieur étant utilisé sur un composant - la raison est tout à fait compréhensible car ref n'est PAS un prop (similaire à key) afin qu'il ne soit pas transmis, il fera donc 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 ; } } return React.forwardRef((props, ref) => { return ; }); }

Limites d'erreur

Plus les choses deviennent complexes, plus la probabilité que quelque chose se passe mal est élevée. C'est pourquoi 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 l'ensemble de 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é supplémentaire de flexibilité 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, ou 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 le essayer / attraper approche.

Les limites d'erreur sont également un endroit où vous pouvez envoyer des informations au Enregistreur d'erreurs que vous utilisez (dans la méthode du 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 Help, something went wrong. ; } return this.props.children; } }

Composants d'ordre supérieur

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 l'avez déjà fait). 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 appelez d'abord une fonction avec des configurations qui retourne plus tard une fonction qui prend un composant d'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 HOC wrapper (vous savez donc 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 là-bas en le remontant tout le temps et en perdant 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 sur vous-même.
• Le mentionné Réfs ne sont pas passés, utilisez donc 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 ( ); } }; }

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 / en ligne normaux s'appliquent ici comme d'habitude 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 avec des objets avec des valeurs correctes pour chacun. Les attributs de style sont également camelCased, donc border-radius devient borderRadius et ainsi de suite.

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

Une autre solution également populaire dans React est CSS-in-JS (par exemple, le emotion bibliothèque). Pour rappel, les modules CSS et les émotions (ou CSS-in-JS en général) sont non limité réagir.

Crochets dans React

Crochets sont probablement l'ajout le plus attendu de 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 excellente fonctionnalité. Ce sont essentiellement des fonctions qui ouvrent de nouvelles opportunités, telles que:

• Permet de supprimer un grand nombre de class composants que nous n'avons utilisés 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.
• Facilite la réflexion et le test des fonctions, par exemple en utilisant le react-testing-bibliothèque .
• Peut également prendre des paramètres, et le résultat de l'un peut être facilement utilisé par un autre hook (par exemple, setState from useState in useEffect).
• Minifie bien mieux que les classes, ce qui a tendance à être un peu plus problématique 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 tout spécialiste Développeur React .

Il y a peu de hooks React qui sont inclus par défaut. Les trois éléments 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, fondamentalement, toute la construction est vraiment simple et ressemble à:

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

Il est appelé avec initialState (valeur) et renvoie un tableau avec deux éléments avec. Grâce à l'affectation de déstructuration des tableaux, nous pouvons affecter les variables à ces éléments tout de suite. 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 assez facile, non?

De plus, en raison du fait que de tels composants étaient 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 composants de classe et composants de fonction semblent être plus conformes à ce qu'ils font réellement, du moins à partir de 16.8.0.

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

setCounter(prevCounter => prevCounter + 1)}>+ setCounter(prevCounter => prevCounter - 1)}>-

Cependant, contrairement au this.setState composant de classe qui faisait une fusion superficielle, définir 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 pendant le rendu initial du composant et après cela, elle ne sera plus appelé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), puis composant Ne fera pas rendre.

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 tout ce que nous pouvons trouver utile. Toute fonction que nous passerons à useEffect sera exécuté après le rendu, et il le sera après chaque rendu à moins que nous ajoutions une limitation concernant les modifications des propriétés qui doivent être réexécutées comme deuxième argument de la fonction. Si nous voulons l'exécuter uniquement lors du montage et le nettoyer lors du démontage, nous devons simplement y passer 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 ( {counter} setCounter(prevCounter => prevCounter + 1)}>+ setCounter(prevCounter => prevCounter - 1)}>- ); };

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 hook 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 fournit à quel contexte nous voulons accéder (un objet qui a été retourné par la fonction createContext) et en retour, il nous fournit la valeur de ce contexte.

const context = useContext(Context);

Enfin, pour écrire votre propre hook, vous pouvez simplement écrire quelque chose comme ce qui suit:

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 la méthode régulière useState hook pour lequel nous attribuons comme valeur initiale la largeur de la fenêtre. Puis dans useEffect, nous ajoutons un auditeur qui déclenchera handleResize à chaque redimensionnement de la fenêtre. Nous clarifions également après que le composant sera démonté (regardez le retour dans useEffect). Facile?

Remarque: Le mot utilisation 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, appeler des hooks à partir de fonctions JS normales.

Vérification des types

React avait sa propre vérification des accessoires, avant que Flow et TypeScript ne soient une option.

PropTypes vérifie si les propriétés (accessoires) qui sont reçues par un composant React et vérifie si elles correspondent à 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 sont 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ées si les propriétés ne sont pas définies ( indéfini est le seul cas). DefaultProps ne sont pas liés aux PropTypes, mais ils peuvent résoudre certains avertissements qui peuvent apparaître en raison de PropTypes.

laquelle de ces raisons n'est pas une raison pour laquelle la sécurisation des applications Web côté serveur est difficile ?

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

• Manuscrit 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 offre une fonctionnalité de saisie semi-automatique supérieure pour le développement. Il améliore également considérablement le refactoring. En raison du support Microsoft, qui possède une vaste expérience des langues dactylographiées, c'est également un choix plutôt sûr.
• Couler 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) depuis le début.

Personnellement, je trouve TypeScript plus rapide (pratiquement instantané), en particulier en saisie semi-automatique, ce 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 l'utilisation optionnelle dans les fichiers, où vous ajoutez simplement // @flow au début du fichier pour commencer la vérification de type. De plus, d'après ce que je peux dire, il semble que TypeScript a finalement gagné la bataille contre Flow - il est bien plus populaire maintenant, et certaines des bibliothèques les plus populaires sont en train d'être 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 frontaux, l'approche la plus simple serait 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 peuvent en fait être plus faciles à démarrer.

Production et performances de réaction

Le changement le plus fondamental et le plus évident que vous devez faire pour le mode de production est de passer en «production» pour DefinePlugin et ajoutez UglifyJsPlugin dans le cas de Webpack. Dans le cas de l'ARC, 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 Outils de développement React , qui vous donnera une indication du type de build que vous utilisez (production vs développement). Les étapes susmentionnées permettront à votre application de s'exécuter sans contrôles 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 «fournisseur + bundle» ou peut-être «fournisseur + plus petite pièce 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 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 lorsque vous vous rendez compte qu’elles risquent de ne pas changer pendant longtemps (voire jamais). De plus, les fichiers plus volumineux sont meilleurs pour le gzipping, donc 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 du code peut apparaître de plus de manières que ce qui est suggéré ici, mais concentrons-nous sur ce que nous avons disponible dans CRA et React lui-même. Fondamentalement, pour diviser le code en différents morceaux, nous pouvons utiliser import() qui fonctionne grâce à Webpack (import lui-même est une proposition à l'étape 3 à partir de maintenant, donc il ne fait pas encore partie du standard du langage). Chaque fois que Webpack voit import, il saura qu'il doit commencer le fractionnement du code à ce stade et ne peut pas l'inclure dans le bundle principal (le code qu'il contient dans l'importation).

Maintenant, nous pouvons le connecter avec React.lazy() ce 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() montrera le composant nous import(), mais import() peut récupérer un morceau plus gros que ce composant unique. Par exemple, ce composant particulier peut avoir d’autres bibliothèques, plus de code, etc., donc un seul fichier n’est pas nécessaire - il peut s'agir de plusieurs 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 secours 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 ( ); }

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

Performances du code de réaction

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 Onglet Performances de Chrome , 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 est d'utiliser Profileur DevTools qui est devenu disponible dans React 16.5+, et avec la coopération de shouldComponentUpdate (ou PureComponent, qui a été expliqué dans première partie de ce tutoriel ), nous pouvons améliorer les performances de certains composants critiques.

De toute évidence, il est optimal d'utiliser les meilleures pratiques de base pour le Web, comme la suppression 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 négligée très facilement, surtout si vous ne faites que vous familiariser avec React.

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

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

webpack résoudre node_modules

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

Oui, il y a certaines choses qui 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 à 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 pense pas qu’ils remplaceront purement et simplement, mais je crois qu’ils pourraient bien se compléter.

En ce qui concerne le court terme, les hooks viennent de rentrer chez React. C'est probablement le plus grand changement depuis la réécriture dans React, car ils ouvriront de nombreuses possibilités et amélioreront d'autres composants de fonction (et ils sont vraiment en train d'être hypnotisés maintenant).

Enfin, comme c’est ce que j’ai fait récemment, il y a Réagir natif . Pour moi, c'est une excellente technologie qui a tellement changé au cours des deux dernières années (le manque de lien natif de réaction était probablement le plus gros problème pour la plupart des gens, et il y avait évidemment beaucoup de bugs). 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.

En relation: Récupération de données obsolètes lors de la revalidation avec React Hooks: un guide

Comprendre les bases

Que sont les hooks React?

Les hooks sont des fonctions qui vous permettent de vous connecter à l'état de React et aux fonctionnalités du cycle de vie des composants de fonction.

De quoi se souvenir quelque chose à leur sujet?

Ils doivent commencer par «use» et ne doivent être appelés qu'à partir des fonctions des composants React. Vous pouvez également créer vos propres crochets!

Les composants incontrôlés ont-ils un sens?

Dans certaines situations, oui. Lors du téléchargement de fichiers, ils sont nécessaires, mais dans la plupart des cas, les composants contrôlés sont plus faciles à utiliser.

Tout cela peut-il être utilisé dans React Native?

La plupart. Tout d'abord, les performances liées au fractionnement ne sont pas là dans RN (cela peut être fait mais pas hors de la boîte - il faut plutôt le pirater car Metro ne fonctionne pas encore avec de telles choses). Tout le reste s'applique à RN.

Quelle référence dois-je utiliser?

N'UTILISEZ PAS l'ancien. La méthode préférée est d'utiliser createRef, mais le rappel devrait être parfait.

Crochets, HOC ou accessoires de rendu?

Si quelque chose peut être résolu avec des crochets, j'utiliserais des crochets. Ils sont beaucoup plus faciles (du moins pour moi) à travailler car ils semblent plus faciles à partager avec différents composants et ils n'apportent pas de pyramide de malheur dans le cas des accessoires de rendu ou de la chose `` d'où cela vient ''. HOC.

Pourquoi les hameçons étaient-ils si attendus?

Ils peuvent résoudre certains problèmes de partage de code que nous avions précédemment avec l'utilisation des HOC et rendre les modèles d'accessoires qui parfois pourraient rendre un code un peu compliqué sans raison.