Cette page contient une référence API détaillée pour la définition de la classe de composant React. Cela suppose que vous êtes familier avec les concepts fondamentaux de React, tels que les composants et les accessoires, ainsi que l’État et le Cycle de vie. Si ce n’est pas le cas, lisez-les d’abord.
Aperçu
React vous permet de définir des composants en tant que classes ou fonctions. Les composants définis comme des classes fournissent actuellement plus de fonctionnalités qui sont décrites en détail sur cette page. Pour définir une classe de composants React, vous devez étendre React.Component:
class Welcome extends React.Component { render() { return <h1>Hello, {this.props.name}</h1>; }}La seule méthode que vous devez définir dans une sous-classe React.Component est appelée render(). Toutes les autres méthodes décrites sur cette page sont facultatives.
Nous vous recommandons fortement de ne pas créer vos propres classes de composants de base. Dans les composants React, la réutilisation du code est principalement réalisée par la composition plutôt que par l’héritage.
Remarque:
React ne vous force pas à utiliser la syntaxe de la classe ES6. Si vous préférez l’éviter, vous pouvez utiliser le module
create-react-classou une abstraction personnalisée similaire à la place. Jetez un œil à l’utilisation de React sans ES6 pour en savoir plus.
Le cycle de vie du composant
Chaque composant dispose de plusieurs » méthodes de cycle de vie” que vous pouvez remplacer pour exécuter du code à des moments particuliers du processus. Vous pouvez utiliser ce diagramme de cycle de vie comme une feuille de triche. Dans la liste ci-dessous, les méthodes de cycle de vie couramment utilisées sont marquées en gras. Les autres existent pour des cas d’utilisation relativement rares.
Montage
Ces méthodes sont appelées dans l’ordre suivant lorsqu’une instance d’un composant est créée et insérée dans le DOM :
-
constructor() -
static getDerivedStateFromProps() render()-
componentDidMount()
Remarque:
Ces méthodes sont considérées comme héritées et vous devez les éviter dans le nouveau code:
UNSAFE_componentWillMount()
Mise à jour
Une mise à jour peut être causée par des modifications des accessoires ou de l’état. Ces méthodes sont appelées dans l’ordre suivant lorsqu’un composant est rendu à nouveau :
-
static getDerivedStateFromProps() -
shouldComponentUpdate() -
render() -
getSnapshotBeforeUpdate() componentDidUpdate()
Remarque:
Ces méthodes sont considérées comme héritées et vous devez les éviter dans le nouveau code:
UNSAFE_componentWillUpdate()UNSAFE_componentWillReceiveProps()
Démontage
Cette méthode est appelée lorsqu’un composant est supprimé du DOM :
-
componentWillUnmount()
Gestion des erreurs
Ces méthodes sont appelées lorsqu’il y a une erreur lors du rendu, dans une méthode de cycle de vie ou dans le constructeur d’un composant enfant.
static getDerivedStateFromError()componentDidCatch()
Autres API
Chaque composant fournit également d’autres API:
setState()forceUpdate()
Propriétés de la classe
-
defaultProps displayName
Propriétés d’instance
-
props state
Référence
Méthodes de cycle de vie couramment utilisées
Les méthodes de cette section couvrent la grande majorité des cas d’utilisation que vous rencontrerez en créant des composants React. Pour une référence visuelle, consultez ce diagramme de cycle de vie.
render()
render()La méthode render() est la seule méthode requise dans un composant de classe.
Lorsqu’il est appelé, il doit examiner this.props et this.state et renvoyer l’un des types suivants:
- Éléments de réaction. Généralement créé via JSX. Par exemple,
<div />et<MyComponent />sont des éléments React qui demandent à React de rendre respectivement un nœud DOM ou un autre composant défini par l’utilisateur. - Tableaux et fragments. Vous permet de renvoyer plusieurs éléments à partir du rendu. Voir la documentation sur les fragments pour plus de détails.
- Portails. Vous permet de rendre les enfants dans un sous-arbre DOM différent. Voir la documentation sur les portails pour plus de détails.
- Chaîne et nombres. Ceux-ci sont rendus sous forme de nœuds de texte dans le DOM.
- Booléens ou
null. Ne rend rien. (Existe principalement pour prendre en charge le motifreturn test && <Child />, oùtestest booléen.)
La fonction render() doit être pure, ce qui signifie qu’elle ne modifie pas l’état du composant, elle renvoie le même résultat à chaque appel et n’interagit pas directement avec le navigateur.
Si vous devez interagir avec le navigateur, effectuez votre travail dans componentDidMount() ou les autres méthodes de cycle de vie à la place. Garder render()pur rend les composants plus faciles à penser.
Remarque
render()ne sera pas invoqué sishouldComponentUpdate()renvoie false.
constructor()
constructor(props)Si vous n’initialisez pas l’état et que vous ne liez pas de méthodes, vous n’avez pas besoin d’implémenter un constructeur pour votre composant React.
Le constructeur d’un composant React est appelé avant son montage. Lors de l’implémentation du constructeur pour une sous-classe React.Component, vous devez appeler super(props) avant toute autre instruction. Sinon, this.props ne sera pas défini dans le constructeur, ce qui peut entraîner des bogues.
En règle générale, dans React, les constructeurs ne sont utilisés qu’à deux fins :
- Initialiser l’état local en attribuant un objet à
this.state. - Lier des méthodes de gestionnaire d’événements à une instance.
Vous ne devez pas appeler setState()dans le constructor(). Au lieu de cela, si votre composant doit utiliser l’état local, attribuez l’état initial à this.state directement dans le constructeur :
constructor(props) { super(props); // Don't call this.setState() here! this.state = { counter: 0 }; this.handleClick = this.handleClick.bind(this);}Le constructeur est le seul endroit où vous devez attribuer directement this.state. Dans toutes les autres méthodes, vous devez utiliser this.setState() à la place.
Évitez d’introduire des effets secondaires ou des abonnements dans le constructeur. Pour ces cas d’utilisation, utilisez plutôt componentDidMount().
Remarque
Évitez de copier les accessoires dans l’état! C’est une erreur courante:
constructor(props) { super(props); // Don't do this! this.state = { color: props.color };}Le problème est que c’est à la fois inutile (vous pouvez utiliser
this.props.colordirectement à la place) et crée des bogues (les mises à jour de la propcolorne seront pas reflétées dans l’état).N’utilisez ce modèle que si vous souhaitez intentionnellement ignorer les mises à jour des accessoires. Dans ce cas, il est logique de renommer l’accessoire pour l’appeler
initialColoroudefaultColor. Vous pouvez ensuite forcer un composant à ” réinitialiser » son état interne en changeant sonkeysi nécessaire.Lisez notre article de blog sur éviter l’état dérivé pour savoir quoi faire si vous pensez avoir besoin d’un état pour dépendre des accessoires.
componentDidMount()
componentDidMount()componentDidMount() est appelé immédiatement après le montage d’un composant (inséré dans l’arborescence). L’initialisation qui nécessite des nœuds DOM devrait aller ici. Si vous devez charger des données à partir d’un point de terminaison distant, c’est un bon endroit pour instancier la demande réseau.
Cette méthode est un bon endroit pour configurer des abonnements. Si vous faites cela, n’oubliez pas de vous désabonner dans componentWillUnmount().
Vous pouvez appeler setState()immédiatement dans componentDidMount(). Cela déclenchera un rendu supplémentaire, mais cela se produira avant que le navigateur ne mette à jour l’écran. Cela garantit que même si render() sera appelé deux fois dans ce cas, l’utilisateur ne verra pas l’état intermédiaire. Utilisez ce modèle avec prudence car il provoque souvent des problèmes de performances. Dans la plupart des cas, vous devriez pouvoir attribuer l’état initial dans constructor() à la place. Cela peut cependant être nécessaire pour des cas tels que les modaux et les info-bulles lorsque vous devez mesurer un nœud DOM avant de rendre quelque chose qui dépend de sa taille ou de sa position.
componentDidUpdate()
componentDidUpdate(prevProps, prevState, snapshot)componentDidUpdate() est appelé immédiatement après la mise à jour. Cette méthode n’est pas appelée pour le rendu initial.
Utilisez ceci comme une opportunité d’opérer sur le DOM lorsque le composant a été mis à jour. C’est également un bon endroit pour faire des requêtes réseau tant que vous comparez les accessoires actuels aux accessoires précédents (par ex. une demande réseau peut ne pas être nécessaire si les accessoires n’ont pas changé).
componentDidUpdate(prevProps) { // Typical usage (don't forget to compare props): if (this.props.userID !== prevProps.userID) { this.fetchData(this.props.userID); }}Vous pouvez appeler setState()immédiatement dans componentDidUpdate() mais notez qu’il doit être enveloppé dans une condition comme dans l’exemple ci-dessus, sinon vous provoquerez une boucle infinie. Cela entraînerait également un re-rendu supplémentaire qui, bien qu’il ne soit pas visible par l’utilisateur, peut affecter les performances du composant. Si vous essayez de ”refléter » un état à un accessoire venant d’en haut, envisagez d’utiliser l’accessoire directement à la place. En savoir plus sur les raisons pour lesquelles la copie des accessoires dans l’état provoque des bogues.
Si votre composant implémente le cycle de vie getSnapshotBeforeUpdate() (ce qui est rare), la valeur qu’il renvoie sera transmise en tant que troisième paramètre « snapshot” à componentDidUpdate(). Sinon, ce paramètre ne sera pas défini.
Remarque
componentDidUpdate()ne sera pas invoqué sishouldComponentUpdate()renvoie false.
componentWillUnmount()
componentWillUnmount()componentWillUnmount() est appelé immédiatement avant qu’un composant ne soit démonté et détruit. Effectuez tout nettoyage nécessaire dans cette méthode, tel que l’invalidation des minuteries, l’annulation des demandes réseau ou le nettoyage des abonnements créés dans componentDidMount().
Vous ne devez pas appeler setState() dans componentWillUnmount() car le composant ne sera jamais restitué. Une fois qu’une instance de composant est démonté, il ne sera plus jamais monté.
Méthodes de cycle de vie rarement utilisées
Les méthodes de cette section correspondent à des cas d’utilisation inhabituels. Ils sont pratiques de temps en temps, mais la plupart de vos composants n’en ont probablement pas besoin. Vous pouvez voir la plupart des méthodes ci-dessous sur ce diagramme de cycle de vie si vous cliquez sur la case à cocher ”Afficher les cycles de vie les moins courants » en haut de celui-ci.
shouldComponentUpdate()
shouldComponentUpdate(nextProps, nextState)Utilisez shouldComponentUpdate() pour indiquer à React si la sortie d’un composant n’est pas affectée par le changement d’état ou d’accessoires en cours. Le comportement par défaut est de restituer à chaque changement d’état, et dans la grande majorité des cas, vous devez vous fier au comportement par défaut.
shouldComponentUpdate() est appelé avant le rendu lorsque de nouveaux accessoires ou états sont reçus. Par défaut, true. Cette méthode n’est pas appelée pour le rendu initial ou lorsque forceUpdate() est utilisée.
Cette méthode n’existe qu’en tant qu’optimisation des performances. Ne comptez pas dessus pour « empêcher » un rendu, car cela peut entraîner des bugs. Envisagez d’utiliser le PureComponent intégré au lieu d’écrire shouldComponentUpdate() à la main. PureComponent effectue une comparaison superficielle des accessoires et de l’état, et réduit les chances que vous sautiez une mise à jour nécessaire.
Si vous êtes sûr de vouloir l’écrire à la main, vous pouvez comparer this.props avec nextProps et this.state avec nextState et renvoyer false pour indiquer à React que la mise à jour peut être ignorée. Notez que le retour de false n’empêche pas les composants enfants de se restituer lorsque leur état change.
Nous ne recommandons pas de vérifier l’égalité en profondeur ou d’utiliser JSON.stringify() dans shouldComponentUpdate(). Il est très inefficace et nuira aux performances.
Actuellement, si shouldComponentUpdate() renvoie false, alors UNSAFE_componentWillUpdate()render(), et componentDidUpdate() ne sera pas invoqué. À l’avenir, React peut traiter shouldComponentUpdate() comme un indice plutôt qu’une directive stricte, et renvoyer false peut toujours entraîner un nouveau rendu du composant.
static getDerivedStateFromProps()
static getDerivedStateFromProps(props, state)getDerivedStateFromProps est appelé juste avant d’appeler la méthode de rendu, à la fois sur le montage initial et sur les mises à jour suivantes. Il doit renvoyer un objet pour mettre à jour l’état, ou null pour ne rien mettre à jour.
Cette méthode existe pour de rares cas d’utilisation où l’état dépend des changements dans les accessoires au fil du temps. Par exemple, cela peut être pratique pour implémenter un composant <Transition> qui compare ses enfants précédents et suivants pour décider lequel d’entre eux doit s’animer.
La dérivation de l’état conduit à un code détaillé et rend vos composants difficiles à penser.Assurez-vous de connaître des alternatives plus simples:
- Si vous devez effectuer un effet secondaire (par exemple, une récupération de données ou une animation) en réponse à un changement d’accessoires, utilisez à la place le cycle de vie
componentDidUpdate. - Si vous souhaitez recalculer certaines données uniquement lorsqu’une accessoire change, utilisez plutôt un assistant de mémorisation.
- Si vous souhaitez « réinitialiser” un état lorsqu’une prop change, envisagez de rendre un composant entièrement contrôlé ou totalement incontrôlé avec un
keyà la place.
Cette méthode n’a pas accès à l’instance du composant. Si vous le souhaitez, vous pouvez réutiliser du code entre getDerivedStateFromProps() et les autres méthodes de classe en extrayant des fonctions pures des accessoires et de l’état du composant en dehors de la définition de classe.
Notez que cette méthode est déclenchée à chaque rendu, quelle qu’en soit la cause. Cela contraste avec UNSAFE_componentWillReceiveProps, qui ne se déclenche que lorsque le parent provoque un nouveau rendu et non à la suite d’un setState local.
getSnapshotBeforeUpdate()
getSnapshotBeforeUpdate(prevProps, prevState)getSnapshotBeforeUpdate() est invoqué juste avant que la sortie la plus récemment rendue ne soit validée, par exemple dans le DOM. Il permet à votre composant de capturer certaines informations du DOM (par exemple, la position de défilement) avant qu’elles ne soient potentiellement modifiées. Toute valeur renvoyée par ce cycle de vie sera transmise en tant que paramètre à componentDidUpdate().
Ce cas d’utilisation n’est pas courant, mais il peut se produire dans les interfaces utilisateur comme un fil de discussion qui doit gérer la position de défilement d’une manière spéciale.
Une valeur d’instantané (ou null) doit être renvoyée.
Par exemple :
class ScrollingList extends React.Component { constructor(props) { super(props); this.listRef = React.createRef(); } getSnapshotBeforeUpdate(prevProps, prevState) { // Are we adding new items to the list? // Capture the scroll position so we can adjust scroll later. if (prevProps.list.length < this.props.list.length) { const list = this.listRef.current; return list.scrollHeight - list.scrollTop; } return null; } componentDidUpdate(prevProps, prevState, snapshot) { // If we have a snapshot value, we've just added new items. // Adjust scroll so these new items don't push the old ones out of view. // (snapshot here is the value returned from getSnapshotBeforeUpdate) if (snapshot !== null) { const list = this.listRef.current; list.scrollTop = list.scrollHeight - snapshot; } } render() { return ( <div ref={this.listRef}>{/* ...contents... */}</div> ); }}Dans les exemples ci-dessus, il est important de lire la propriété scrollHeight dans getSnapshotBeforeUpdate car il peut y avoir des retards entre les cycles de vie de phase de « rendu” (comme render) et les cycles de vie de phase « commit” (comme getSnapshotBeforeUpdate et componentDidUpdate).
Limites d’erreur
Les limites d’erreur sont des composants React qui détectent les erreurs JavaScript n’importe où dans leur arbre de composants enfant, enregistrent ces erreurs et affichent une interface utilisateur de secours au lieu de l’arbre de composants qui s’est écrasé. Les limites d’erreur détectent les erreurs lors du rendu, dans les méthodes de cycle de vie et dans les constructeurs de l’arbre entier en dessous.
Un composant de classe devient une limite d’erreur s’il définit l’une (ou les deux) des méthodes de cycle de vie static getDerivedStateFromError() ou componentDidCatch(). La mise à jour de l’état de ces cycles de vie vous permet de capturer une erreur JavaScript non gérée dans l’arborescence ci-dessous et d’afficher une interface utilisateur de secours.
Utilisez uniquement les limites d’erreur pour récupérer des exceptions inattendues ; n’essayez pas de les utiliser pour le flux de contrôle.
Pour plus de détails, voir Gestion des erreurs dans React 16.
Remarque
Les limites d’erreur détectent uniquement les erreurs dans les composants situés en dessous dans l’arborescence. Une limite d’erreur ne peut pas détecter une erreur en elle-même.
static getDerivedStateFromError()
static getDerivedStateFromError(error)Ce cycle de vie est invoqué après qu’une erreur a été lancée par un descendant component.It reçoit l’erreur qui a été levée en tant que paramètre et doit renvoyer une valeur à l’état de mise à jour.
class ErrorBoundary extends React.Component { constructor(props) { super(props); this.state = { hasError: false }; } static getDerivedStateFromError(error) { // Update state so the next render will show the fallback UI. return { hasError: true }; } render() { if (this.state.hasError) { // You can render any custom fallback UI return <h1>Something went wrong.</h1>; } return this.props.children; }}Remarque
getDerivedStateFromError()est appelé pendant la phase de rendu, les effets secondaires ne sont donc pas autorisés.Pour ces cas d’utilisation, utilisez plutôtcomponentDidCatch().
componentDidCatch()
componentDidCatch(error, info)Ce cycle de vie est invoqué après qu’une erreur a été générée par un descendant component.It reçoit deux paramètres :
-
error– L’erreur qui a été levée. -
info– Un objet avec une clécomponentStackcontenant des informations sur le composant ayant généré l’erreur.
componentDidCatch() est appelé pendant la phase « commit », donc les effets secondaires sont permitted.It devrait être utilisé pour des choses comme les erreurs de journalisation:
class ErrorBoundary extends React.Component { constructor(props) { super(props); this.state = { hasError: false }; } static getDerivedStateFromError(error) { // Update state so the next render will show the fallback UI. return { hasError: true }; } componentDidCatch(error, info) { // Example "componentStack": // in ComponentThatThrows (created by App) // in ErrorBoundary (created by App) // in div (created by App) // in App logComponentStackToMyService(info.componentStack); } render() { if (this.state.hasError) { // You can render any custom fallback UI return <h1>Something went wrong.</h1>; } return this.props.children; }}Les versions de production et de développement de React diffèrent légèrement de la manière dont componentDidCatch() gère les erreurs.
Au cours du développement, les erreurs vont gonfler jusqu’à window, cela signifie que tout window.onerror ou window.addEventListener('error', callback) interceptera les erreurs qui ont été détectées par componentDidCatch().
En production, les erreurs ne s’afficheront pas, ce qui signifie que tout gestionnaire d’erreurs ancêtre ne recevra que des erreurs non explicitement détectées par componentDidCatch().
Remarque
En cas d’erreur, vous pouvez rendre une interface utilisateur de secours avec
componentDidCatch()en appelantsetState, mais cela sera obsolète dans une prochaine version.Utilisezstatic getDerivedStateFromError()pour gérer le rendu de secours à la place.
Méthodes de cycle de vie héritées
Les méthodes de cycle de vie ci-dessous sont marquées comme « héritées”. Ils fonctionnent toujours, mais nous ne recommandons pas de les utiliser dans le nouveau code. Vous pouvez en savoir plus sur la migration des méthodes de cycle de vie héritées dans cet article de blog.
UNSAFE_componentWillMount()
UNSAFE_componentWillMount()Remarque
Ce cycle de vie était précédemment nommé
componentWillMount. Ce nom continuera à fonctionner jusqu’à la version 17. Utilisez le codemodrename-unsafe-lifecyclespour mettre à jour automatiquement vos composants.
UNSAFE_componentWillMount() est appelé juste avant le montage. Il est appelé avant render(), donc appeler setState() de manière synchrone dans cette méthode ne déclenchera pas de rendu supplémentaire. Généralement, nous recommandons d’utiliser le constructor() à la place pour l’initialisation de l’état.
Évitez d’introduire des effets secondaires ou des abonnements dans cette méthode. Pour ces cas d’utilisation, utilisez plutôt componentDidMount().
C’est la seule méthode de cycle de vie appelée sur le rendu du serveur.
UNSAFE_componentWillReceiveProps()
UNSAFE_componentWillReceiveProps(nextProps)Remarque
Ce cycle de vie était précédemment nommé
componentWillReceiveProps. Ce nom continuera à fonctionner jusqu’à la version 17. Utilisez le codemodrename-unsafe-lifecyclespour mettre à jour automatiquement vos composants.
Remarque:
L’utilisation de cette méthode de cycle de vie entraîne souvent des bugs et des incohérences
- Si vous devez effectuer un effet secondaire (par exemple, une récupération de données ou une animation) en réponse à un changement d’accessoires, utilisez
componentDidUpdatecycle de vie à la place.- Si vous avez utilisé
componentWillReceivePropspour recalculer certaines données uniquement lorsqu’une accessoire change, utilisez plutôt un assistant de mémorisation.- Si vous avez utilisé
componentWillReceivePropspour ”réinitialiser » un état lorsqu’une prop change, envisagez de rendre un composant entièrement contrôlé ou totalement incontrôlé avec unkeyà la place.Pour d’autres cas d’utilisation, suivez les recommandations de cet article de blog sur l’état dérivé.
UNSAFE_componentWillReceiveProps() est invoqué avant qu’un composant monté ne reçoive de nouveaux accessoires. Si vous devez mettre à jour l’état en réponse aux modifications de prop (par exemple, pour le réinitialiser), vous pouvez comparer this.props et nextProps et effectuer des transitions d’état en utilisant this.setState() dans cette méthode.
Notez que si un composant parent provoque le re-rendu de votre composant, cette méthode sera appelée même si les accessoires n’ont pas changé. Assurez-vous de comparer les valeurs actuelles et suivantes si vous souhaitez uniquement gérer les modifications.
React n’appelle pas UNSAFE_componentWillReceiveProps() avec les accessoires initiaux lors du montage. Il n’appelle cette méthode que si certains accessoires du composant peuvent être mis à jour. Appeler this.setState() ne déclenche généralement pas UNSAFE_componentWillReceiveProps().
UNSAFE_componentWillUpdate()
UNSAFE_componentWillUpdate(nextProps, nextState)Remarque
Ce cycle de vie était précédemment nommé
componentWillUpdate. Ce nom continuera à fonctionner jusqu’à la version 17. Utilisez le codemodrename-unsafe-lifecyclespour mettre à jour automatiquement vos composants.
UNSAFE_componentWillUpdate() est appelé juste avant le rendu lorsque de nouveaux accessoires ou états sont reçus. Utilisez-le comme une occasion d’effectuer la préparation avant qu’une mise à jour ne se produise. Cette méthode n’est pas appelée pour le rendu initial.
Notez que vous ne pouvez pas appeler this.setState() ici ; vous ne devez pas non plus faire autre chose (par exemple envoyer une action Redux) qui déclencherait une mise à jour d’un composant React avant le retour de UNSAFE_componentWillUpdate().
Typiquement, cette méthode peut être remplacée par componentDidUpdate(). Si vous lisiez à partir du DOM dans cette méthode (par exemple pour enregistrer une position de défilement), vous pouvez déplacer cette logique vers getSnapshotBeforeUpdate().
Remarque
UNSAFE_componentWillUpdate()ne sera pas invoqué sishouldComponentUpdate()renvoie false.
Autres API
Contrairement aux méthodes de cycle de vie ci-dessus (que React appelle pour vous), les méthodes ci-dessous sont les méthodes que vous pouvez appeler à partir de vos composants.
Il n’y en a que deux : setState() et forceUpdate().
setState()
setState(updater, )setState() la file d’attente modifie l’état du composant et indique à React que ce composant et ses enfants doivent être rendus à nouveau avec l’état mis à jour. Il s’agit de la méthode principale que vous utilisez pour mettre à jour l’interface utilisateur en réponse aux gestionnaires d’événements et aux réponses du serveur.
Considérez setState() comme une requête plutôt qu’une commande immédiate pour mettre à jour le composant. Pour une meilleure perception des performances, React peut le retarder, puis mettre à jour plusieurs composants en un seul passage. React ne garantit pas que les changements d’état sont appliqués immédiatement.
setState() ne met pas toujours à jour immédiatement le composant. Il peut lot ou reporter la mise à jour à plus tard. Cela fait de la lecture de this.state juste après l’appel de setState() un piège potentiel. Au lieu de cela, utilisez componentDidUpdate ou un rappel setStatesetState(updater, callback)), dont le déclenchement est garanti une fois la mise à jour appliquée. Si vous devez définir l’état en fonction de l’état précédent, lisez l’argument updater ci-dessous.
setState() conduira toujours à un nouveau rendu à moins que shouldComponentUpdate() renvoie false. Si des objets mutables sont utilisés et que la logique de rendu conditionnelle ne peut pas être implémentée dans shouldComponentUpdate(), appeler setState() uniquement lorsque le nouvel état diffère de l’état précédent évitera des restitutions inutiles.
Le premier argument est une fonction updater avec la signature:
(state, props) => stateChangestate est une référence à l’état du composant au moment où la modification est appliquée. Il ne doit pas être directement muté. Au lieu de cela, les modifications doivent être représentées en construisant un nouvel objet basé sur l’entrée de state et props. Par exemple, supposons que nous voulions incrémenter une valeur dans l’état par props.step:
this.setState((state, props) => { return {counter: state.counter + props.step};});Les state et props reçus par la fonction de mise à jour sont garantis à jour. La sortie du programme de mise à jour est peu fusionnée avec state.
Le deuxième paramètre de setState() est une fonction de rappel facultative qui sera exécutée une fois que setState est terminé et que le composant est rendu à nouveau. Généralement, nous recommandons d’utiliser componentDidUpdate() pour une telle logique à la place.
Vous pouvez éventuellement passer un objet comme premier argument à setState() au lieu d’une fonction :
setState(stateChange)Cela effectue une fusion superficielle de stateChange dans le nouvel état, par exemple pour ajuster un panier quantité d’élément :
this.setState({quantity: 2})Cette forme de setState() est également asynchrone, et plusieurs appels au cours du même cycle peuvent être regroupés en lots. Par exemple, si vous tentez d’incrémenter une quantité d’article plus d’une fois dans le même cycle, cela se traduira par l’équivalent de:
Object.assign( previousState, {quantity: state.quantity + 1}, {quantity: state.quantity + 1}, ...)Les appels suivants remplaceront les valeurs des appels précédents dans le même cycle, de sorte que la quantité ne sera incrémentée qu’une seule fois. Si l’état suivant dépend de l’état actuel, nous vous recommandons d’utiliser la forme de la fonction de mise à jour, à la place :
this.setState((state) => { return {quantity: state.quantity + 1};});Pour plus de détails, voir :
- Guide d’état et de cycle de vie
- En profondeur : Quand et pourquoi les appels
setState()sont-ils groupés ? - En profondeur: Pourquoi
this.staten’est-il pas mis à jour immédiatement?
forceUpdate()
component.forceUpdate(callback)Par défaut, lorsque l’état ou les accessoires de votre composant changent, votre composant sera rendu à nouveau. Si votre méthode render() dépend d’autres données, vous pouvez indiquer à React que le composant doit être rendu à nouveau en appelant forceUpdate().
L’appel de forceUpdate() entraînera l’appel de render() sur le composant, en ignorant shouldComponentUpdate(). Cela déclenchera les méthodes de cycle de vie normales pour les composants enfants, y compris la méthode shouldComponentUpdate() de chaque enfant. React ne mettra toujours à jour le DOM que si le balisage change.
Normalement, vous devriez essayer d’éviter toutes les utilisations de forceUpdate() et ne lire que depuis this.props et this.state dans render().
Propriétés de la classe
defaultProps
defaultPropspeut être défini comme une propriété sur la classe de composant elle-même, pour définir les accessoires par défaut pour la classe. This is used for undefined props, but not for null props. For example:
class CustomButton extends React.Component { // ...}CustomButton.defaultProps = { color: 'blue'};If props.color is not provided, it will be set by default to 'blue':
render() { return <CustomButton /> ; // props.color will be set to blue }If props.color is set to null, it will remain null:
render() { return <CustomButton color={null} /> ; // props.color will remain null }displayName
The displayName string is used in debugging messages. Habituellement, vous n’avez pas besoin de le définir explicitement car il est déduit du nom de la fonction ou de la classe qui définit le composant. Vous pouvez le définir explicitement si vous souhaitez afficher un nom différent à des fins de débogage ou lorsque vous créez un composant d’ordre supérieur, consultez Envelopper le nom d’affichage pour un débogage facile pour plus de détails.
Propriétés d’instance
props
this.props contient les props qui ont été définis par l’appelant de ce composant. Voir Composants et accessoires pour une introduction aux accessoires.
En particulier, this.props.children est un accessoire spécial, généralement défini par les balises enfants dans l’expression JSX plutôt que dans la balise elle-même.
état
L’état contient des données spécifiques à ce composant qui peuvent changer avec le temps. L’état est défini par l’utilisateur et doit être un objet JavaScript simple.
Si une valeur n’est pas utilisée pour le rendu ou le flux de données (par exemple, un ID de minuterie), vous n’avez pas à la mettre dans l’état. Ces valeurs peuvent être définies comme des champs sur l’instance du composant.
Voir État et cycle de vie pour plus d’informations sur l’état.
Ne jamais muter this.state directement, car appeler setState() peut ensuite remplacer la mutation que vous avez effectuée. Traitez this.state comme si c’était immuable.