Tutoriel React : comment démarrer et comment il se compare

Le front-end et JavaScript en particulier sont un monde étrange. La quantité de nouvelles choses déployées quotidiennement est souvent ridiculisée par les personnes qui ne travaillent pas avec eux, et beaucoup le font. Pourtant, parfois, nous sommes un peu submergés par de nouvelles informations, bibliothèques et discussions, et nous aimerions quelque chose de stable, comme un refuge sûr pour les navires où nous pouvons rester un peu plus longtemps. Dernièrement, React semble être ce port docile dans une mer d'évolution dynamique de JavaScript.

Dans cet esprit, nous avons décidé de produire ce didacticiel React en plusieurs parties, pour présenter ses capacités et voir comment il se compare à Angular et VueJS.

Bien sûr, React n'est pas le seul port que nous pouvons utiliser, mais pour le moment, c'est l'une des solutions les plus populaires, les plus stables et les plus innovantes, et bien qu'il reçoive encore de nombreuses mises à niveau, elles sont plus une option d'amélioration que qu'une nécessité pour la fonction.

L'état de React en 2019

React est une bibliothèque de vues que nous pouvons retracer dès 2011, lorsque son premier prototype, appelé FaxJs, est apparu sur sa page Facebook, React lui-même a été présenté par Jordan Walke (qui est également l'auteur du prototype mentionné) à JSConfUS sur 29 mai 2013, et a été ouvertement disponible sur GitHub le 2 juillet 2013.

React a continué à gagner en popularité en 2014, lorsque des conférences ont commencé à apparaître pour élargir la communauté et populariser React. De mon point de vue, cependant, 2015 a été une année charnière pour React - de grandes entreprises (par exemple, Airbnb et Netflix) ont commencé à aimer et à adopter les solutions React. De plus, React Native est apparu cette année-là. L'idée derrière React Native n'était pas quelque chose d'absolument nouveau, mais c'était intéressant à regarder, d'autant plus qu'il était soutenu par Facebook.

Un autre grand changement a été Redux, une implémentation de Flux. Cela a rendu la gestion de l'état beaucoup plus accessible et plus facile, ce qui en fait la mise en œuvre la plus réussie à ce jour.

Entre alors et maintenant, beaucoup d'autres choses sont devenues disponibles, y compris les outils React, une réécriture de l'algorithme de base, Fiber, un changement de version sémantique, etc. Avance rapide jusqu'à aujourd'hui, nous sommes sur 16.6.3, probablement quelques semaines avant que la nouvelle version avec Hooks ne soit disponible (elle était censée être 16.7.0, mais celle-ci est déjà sortie en raison de quelques correctifs pour React.lazy). React est bien connu et stable et obtient d'excellentes opinions.

Mais qu'est-ce que React ?

Eh bien, si vous êtes développeur front-end et que vous n'en avez pas encore entendu parler, je dois dire que des félicitations s'imposent, car c'est tout un exploit.

Blague à part, React est une bibliothèque de vues déclarative basée sur des composants qui vous aide à créer une interface utilisateur. C'est une bibliothèque, pas un cadre, bien qu'au début, beaucoup de gens l'aient décrit comme ce dernier.

Évidemment, si nous allons ajouter Redux, React Router, etc., il commence à avoir toutes les choses nécessaires pour faire une application régulière d'une seule page, ce qui pourrait être une raison pour laquelle il est parfois décrit à tort comme un framework plutôt qu'une bibliothèque . Si quoi que ce soit, on pourrait faire valoir que, avec tous les composants de cet environnement ensemble, le terme «framework» est quelque peu approprié, mais à lui seul, React n'est qu'une bibliothèque.

Arrêtons-nous avec la nomenclature et concentrons-nous sur ce qui est différent dans React, sur les choses que nous n'avions pas avant sa création. Tout d'abord, lorsque vous pensez à React pour la première fois, vous pensez à JSX, car c'est la première chose qui vous vient à l'esprit lorsque vous regardez le code. JSX est une extension de syntaxe JavaScript qui ressemble quelque peu à HTML/XML. En ce qui concerne React et JSX, nous avons quelques différences avec HTML, par exemple, une classe dans React est className , il n'y a pas de tabindex mais tabIndex , le style accepte les objets JavaScript qui ont des propriétés camelCased, etc.

Il existe quelques différences mineures, mais tout le monde devrait les comprendre en un rien de temps. La gestion des événements passe par, par exemple, les attributs onChange et onClick qui peuvent être utilisés pour attacher une fonction pour gérer les événements. De plus, les composants peuvent ensuite être librement réutilisés et personnalisés à l'aide d'accessoires, il n'y a donc aucune raison d'écrire le même code plusieurs fois.

 import React, { Component } from 'react'; export default class App extends Component { render() { return ( <div>Hello World, {this.props.name}</div> ); } }

Cependant, JSX n'est en fait pas absolument nécessaire dans React. Vous pouvez écrire des fonctions régulières pour créer des éléments sans utiliser JSX. Le même code ci-dessus peut être utilisé comme ci-dessous.

 import React, { Component } from 'react'; export default class App extends Component { render() { return React.createElement( 'div', null, 'Hello World, ', this.props.name ); } }

Évidemment, je ne suggère pas que vous utilisiez une telle syntaxe, bien qu'il y ait des cas où cela pourrait être utile (par exemple, vous voulez introduire une très petite chose et ne voulez pas changer l'environnement de construction).

En fait, j'ai une autre raison pour laquelle j'ai montré l'extrait ci-dessus. Souvent, les développeurs ne comprennent pas pourquoi nous devons faire ce qui suit :

 import React from 'react';

L'extrait doit être explicite. Même si nous extrayons Component , nous avons toujours besoin de React, car Babel transpile au-dessus de JSX en dessous de React.createElement . Donc, si nous n'importons pas React, cela échouera tout simplement pour nous. J'ai mentionné Babel, qui est un outil qui nous aide à introduire des choses qui ne sont pas encore en JavaScript (ou plutôt dans les navigateurs) ou qui en sont en quelque sorte des extensions (ou différents langages comme TypeScript, que Babel prend en charge depuis Babel 7). Merci à Babel :

• JSX sera transformé en fonctions comprises par le navigateur.
• Nous pouvons utiliser de nouvelles fonctionnalités qui ne sont pas encore présentes dans les navigateurs (par exemple, les propriétés de classe).
• Nous pouvons ajouter des fonctionnalités qui se trouvent dans les navigateurs les plus récents mais qui n'existent pas dans les anciens tout en conservant la prise en charge des anciens navigateurs.

En bref, demain est aujourd'hui en JavaScript ; c'est probablement quelque chose qui nécessiterait son propre article. Il convient de mentionner que l'importation React peut également être contournée par d'autres techniques (comme l'introduction de ProvidePlugin via Webpack, etc.), mais en raison de l'espace limité ici, nous l'éviterons et supposerons que l'utilisateur utilisera Create React App ( CRA) (plus d'informations sur cet outil seront mentionnées plus tard).

La deuxième chose importante, et bien plus importante que JSX lui-même, est que React est basé sur le DOM virtuel. En bref, le DOM virtuel est la mémoire d'un arbre idéal qui est représenté par JavaScript que le développeur écrit, qui est ensuite comparé avec le vrai DOM et synchronisé avec lui dans un processus appelé réconciliation.

Comment React se compare-t-il à Angular et Vue ?

Je n'aime pas du tout comparer les bibliothèques, surtout quand nous sommes obligés de comparer des poires à des pommes (bibliothèques vs frameworks, etc.).

Par conséquent, je vais essayer de comparer React à Angular et Vue en utilisant une série de courtes questions et réponses qui n'ont pas grand-chose à voir avec des éléments techniques plutôt que de dire quelque chose comme "X est meilleur que Y car il utilise JSX et non des modèles. ” De tels points sont généralement des préférences personnelles, des choix subjectifs. De plus, la vitesse, l'allocation de mémoire, etc., sont assez similaires dans React et tous ses principaux concurrents (Angular et Vue me viennent à l'esprit). Il existe un très bon rapport sur le sujet, mais gardez ceci à l'esprit : la grande majorité des applications ne ressemblent pas à de très grandes tables qui échangent des lignes dans une table de 10 k. Par conséquent, ces résultats sont également une expérience de vitesse pure. Dans le monde réel, vous ne feriez pas une telle chose en premier lieu.

Jetons donc un coup d'œil à quelques questions relatives à React et comment il se compare à la concurrence :

Je veux avoir beaucoup d'opportunités d'emploi. Quelle est la popularité de React ?

Eh bien, c'est une question facile à répondre - choisissez Réagir. En fait, je dirais que React a environ 6 à 10 fois (un écart assez important, mais il y a des portails où c'est 1:50 et d'autres où c'est 1:6) plus d'offres d'emploi que Vue et 2 à 4 fois plus que angulaire. La demande d'experts React est forte, alors pourquoi Vue est-il si populaire sur GitHub (il a plus d'étoiles que React en fait) mais a moins d'offres d'emploi ? Je n'ai aucune idée.

Je veux une grande communauté, beaucoup de bibliothèques, des solutions rapides aux problèmes qui pourraient survenir.

Réagir. Cherchez pas plus loin.

Est-il facile à utiliser et rend-il le développement agréable ?

Encore une fois, selon les rapports State of JS pour 2018 et 2017, React et Vue jouissent d'une très bonne réputation et la plupart des développeurs disent qu'ils les utiliseraient à nouveau. Angular, d'autre part, a tendance, année après année, à envoyer de plus en plus de personnes disant qu'elles ne l'utiliseraient plus.

Je souhaite créer une nouvelle application monopage, mais je ne souhaite pas rechercher de bibliothèques.

C'est probablement le seul endroit où je dirais qu'Angular est le meilleur choix.

Pas de grandes entreprises. Je veux être le plus indépendant possible, lequel dois-je choisir ?

Vue, c'est le seul indépendant de notre grand trio. (Facebook soutient React, tandis que Google est derrière Angular.)

Début le plus facile et courbe d'apprentissage la plus rapide ?

Voir/Réagir. Je penche pour Vue ici, mais ce n'est que mon opinion personnelle.

Pourquoi? Parce que vous n'avez même pas besoin de connaître JSX (c'est facultatif) et c'est essentiellement HTML + CSS + JavaScript.

Tutoriel React : Premiers pas avec votre première application

La façon la plus simple de commencer avec React de nos jours est d'utiliser CRA, un outil CLI qui crée un projet pour vous et vous aide à éviter tous les paramètres nécessaires pour Webpack/Babel et plus encore. Au lieu de cela, vous vous fiez à la façon dont il est configuré par défaut et à ce qui y a été inclus au fil du temps. Grâce à cela, vous n'avez pas besoin de vous soucier des mises à jour majeures pour certaines bibliothèques critiques.

Bien sûr, plus tard, vous pourrez vous «éjecter» et gérer vous-même chaque aspect en exécutant npm run eject . Cette approche a ses propres points forts, car vous pouvez améliorer votre application avec des éléments qui ne seraient pas disponibles autrement (par exemple, des décorateurs), mais elle peut également être une source de maux de tête car elle nécessite de nombreux fichiers supplémentaires et beaucoup plus de temps.

Donc, la toute première chose à faire est de :

 npx create-react-app {app-name}

Ensuite, npm run start et vous êtes prêt à partir.

Composants de classe et de fonction

Nous devrions commencer par expliquer en quoi ces composants diffèrent. Fondamentalement, chaque composant peut être une fonction ou une classe . La principale différence entre eux est que la classe un a certaines fonctionnalités qui ne sont pas disponibles dans le composant de fonction : ils peuvent avoir un état et utiliser des références, un cycle de vie, etc. C'est l'état actuel du jeu, et à partir de la version 16.7 être appelé en raison de changements déjà mentionnés), nous aurons également des crochets, donc l'état et les références seront possibles avec des crochets.

Il existe deux types de composants de classe : Component et PureComponent . La seule différence entre les deux est que PureComponent fait une comparaison superficielle des accessoires et de l'état - il a ses propres avantages dans une situation où vous ne voulez pas faire de rendus "gaspillés", où un composant et ses enfants sont exactement dans le même état après un rendu. Pourtant, ce n'est qu'une comparaison superficielle; si vous souhaitez implémenter votre propre comparaison (par exemple, parce que vous passez des props complexes), utilisez simplement Component et remplacez shouldComponentUpdate (qui par défaut renvoie true). Depuis 16.6+, quelque chose de similaire est également disponible avec les composants de fonction - grâce à React.memo qui est un composant d'ordre supérieur et se comporte par défaut comme PureComponent (comparaison superficielle), mais il faut un deuxième argument où vous pouvez passer votre propre comparaison d'accessoires personnalisés .

En règle générale, si vous pouvez utiliser le composant de fonction (vous n'avez pas besoin de fonctionnalités de classe), utilisez-le. Bientôt, à partir de 16.7.0, l'utilisation de composants de classe ne sera nécessaire qu'en raison des méthodes de cycle de vie. J'ai tendance à croire que les composants fonctionnels sont plus transparents, plus faciles à raisonner et à comprendre.

Réagir aux méthodes de cycle de vie

Constructeur (accessoires)

• Facultatif, en particulier avec CRA étant si populaire, où les déclarations de champ de classe pour JavaScript sont incluses par défaut. Il est inutile de déclarer si vous liez vos méthodes par la fonction flèche dans le corps de la classe. Un état similaire peut également être initialisé en tant que propriété de classe.
• Doit être utilisé uniquement pour initialiser l'état local des méthodes d'objet et de liaison dans les classes ES6.

composantDidMount()

• Faites des appels Ajax ici.
• Si vous avez besoin d'écouteurs d'événements, d'abonnements, etc., ajoutez-les ici.
• Vous pouvez utiliser setState ici (mais cela rendra le rendu du composant).

componentWillUnmount()

• Nettoie tout ce qui est encore en cours - par exemple, Ajax doit être interrompu, l'abonnement désabonné, les minuteries effacées, etc.
• N'appelez pas setState , car cela ne sert à rien car le composant sera démonté (et vous recevrez un avertissement).

componentDidUpdate(prevProps, prevState, instantané)

• Se produit lorsque le composant vient de terminer la mise à jour (ne se produit pas lors du rendu initial).
• Possède trois paramètres dont l'utilisation est facultative (les accessoires précédents, l'état précédent et un instantané qui n'apparaîtra que si votre composant implémente getSnapshotBeforeUpdate ).
• Se produit uniquement si shouldComponentUpdate renvoie true.
• Si vous utilisez setState ici, vous devez le garder ou vous atterrirez dans une boucle infinie.

shouldComponentUpdate(nextProps, nextState)

• Uniquement pour l'optimisation des performances.
• S'il renvoie false, alors un rendu ne sera PAS appelé.
• PureComponent peut être utilisé à la place si le SCO remplacé n'est qu'une comparaison props/état peu profonde.

getSnapshotBeforeUpdate()

• Peut être utilisé pour conserver certaines informations sur le DOM actuel, par exemple, la position de défilement actuelle qui peut ensuite être réutilisée dans componentDidUpdate pour restaurer la position du défilement.

componentDidCatch(error, info)

• Un endroit où les erreurs de journalisation devraient se produire.
• Peut appeler setState , mais dans les versions futures, il sera abandonné au profit de la méthode statique getDerivedStateFromError(error) , qui mettra à jour l'état en renvoyant une valeur pour mettre à jour l'état.

Il existe deux méthodes supplémentaires qui sont toutes deux statiques et ont été mentionnées dans d'autres explications

getDerivedStateFromError statique (erreur)

• Les informations sur les erreurs sont disponibles ici.
• Devrait retourner une valeur d'objet qui mettra à jour l'état qui peut être utilisé pour gérer les erreurs (en affichant quelque chose).
• Comme il est statique, il n'a pas accès à l'instance du composant lui-même.

getSnapshotBeforeUpdate statique (accessoires, état)

• Devrait être utilisé dans les cas où les accessoires changent avec le temps - par exemple, selon les documents React, cela pourrait être utile pour un composant de transition.
• Comme il est statique, il n'a pas accès à l'instance du composant lui-même.

Notez qu'il existe peu de méthodes supplémentaires disponibles à ce jour, mais elles sont censées être supprimées dans React 17.0, c'est pourquoi elles n'ont pas été mentionnées ici.

État vs accessoires

Commençons par Props , car ils sont plus faciles et plus rapides à expliquer. Les props sont des propriétés qui sont transmises au composant et qui peuvent ensuite être réutilisées dans celui-ci pour afficher des informations/logique métier, etc.

 import React, { Component } from 'react'; export default class App extends Component { render() { return ( <div> <HelloWorld name="Someone :)"/> </div> ); } } const HelloWorld = (props) => <div>Hello {props.name}</div>

Dans l'exemple ci-dessus, le name est un accessoire. Les accessoires sont des éléments en lecture seule et ne peuvent pas être modifiés directement dans les composants enfants. De plus, il y a une mauvaise pratique que les gens font souvent, et c'est de copier les accessoires à l'État et d'opérer sur l'État par la suite. Bien sûr, il y a des cas où vous voulez faire quelque chose comme "l'état initial qui mettra à jour le composant parent après la soumission", mais c'est plus rare - dans un tel scénario, l'alimentation de l'état initial peut avoir un sens. De plus, non seulement des propriétés telles que des chaînes peuvent être transmises aux composants enfants, mais également des nombres, des objets, des fonctions, etc.

Les accessoires ont également une autre chose utile qui s'appelle defaultProps , un champ statique qui peut vous dire quels sont les accessoires par défaut pour un composant (lorsqu'ils ne sont pas transmis au composant, par exemple).

En cas de "lifting state up", où un composant (le parent) a un état qui est ensuite réutilisé par ses enfants (par exemple, un enfant l'affiche et un autre permet l'édition), alors nous devons passer la fonction à l'enfant de parent, ce qui nous permet de mettre à jour l'état local du parent.

State , en revanche, est un état local qui peut être modifié, mais indirectement en utilisant this.setState . Si quelqu'un modifie directement l'état, le composant ne sera pas au courant du changement et il ne sera pas restitué pour refléter les changements mentionnés à l'état.

SetState est une méthode pour changer l'objet d'état local (en faisant une fusion superficielle), et après cela, le composant répond en se restituant. Sachez qu'après l'utilisation de setState , la propriété this.state ne reflétera pas immédiatement les modifications mentionnées dans la fonction (elle a une nature asynchrone) car quelques instances de setState peuvent être regroupées en raison de l'optimisation. Il a plusieurs façons d'être invoqué où l'une de ces possibilités nous permet de faire quelque chose avec le composant juste après la mise à jour de l'état :

• setState({value: '5'})
• setState((state, props) => ({value: state.name + “'s”}))
• setState([object / function like above], () => {}) - ce formulaire nous permet d'attacher callback , qui sera invoqué lorsque l'état reflétera les données que nous voulions avoir (dans le premier argument).

 import React, { Component } from 'react'; export default class App extends Component { state = { name: 'Someone :)' } onClick = () => this.setState({ name: 'You' }) render() { return ( <div> <HelloWorld name={this.state.name} onClick={this.onClick}/> </div> ); } } const HelloWorld = (props) => <div onClick={props.onClick}>Hello {props.name}</div>

Contexte de réaction

React a récemment stabilisé l'API Context (qui était dans React depuis un certain temps, mais était une fonctionnalité expérimentale bien qu'elle soit largement utilisée par certaines des bibliothèques les plus populaires comme Redux), ce qui nous aide à résoudre un problème : le forage d'accessoires. En bref, le forage d'accessoires est un moyen de transmettre des accessoires profondément dans la structure - par exemple, il peut s'agir d'une sorte de thème pour les composants, de localisation pour une langue spécifique, d'informations sur l'utilisateur, etc. Avant Context (ou plutôt avant qu'il ne devienne non expérimental), il était approfondi en passant de manière récursive du parent à l'enfant jusqu'à la dernière feuille (évidemment, il y avait Redux qui pouvait également résoudre le problème). Sachez que cette fonctionnalité résout UNIQUEMENT le forage des accessoires et ne remplace pas des choses comme Redux ou Mobx. Évidemment, si vous utilisiez une bibliothèque de gestion d'état uniquement pour cela, vous pouvez la remplacer librement.

Emballer

Ceci conclut la première partie de notre tutoriel React. Dans les prochains articles, nous espérons aborder des sujets plus avancés, allant du style et des types de vérification au déploiement en production et à l'optimisation des performances.