Pourquoi componentWillMount ne doit pas être utilisé?

Question

Déclencher un appel de serveur pour récupérer des données dans la méthode du cycle de vie componentWillMount une mauvaise pratique?

Et pourquoi il est préférable d'utiliser componentDidMount.

Answer 1

Pour citer @ Dan Abramov

Dans les futures versions de React nous nous attendons à ce que componentWillMount se déclenche plus d'une fois dans certains cas, vous devez donc utiliser componentDidMount pour les demandes de réseau.

En savoir plus ici .

Answer 2

MISE À JOUR - mai/2018
Il existe une nouvelle fonctionnalité pour réagir dans une progression de travail appelée rendu asynchrone .
A partir de réagir v16.3.2 Ces méthodes ne sont pas "sûres" à utiliser:

• componentWillMount
• componentWillReceiveProps
• componentWillUpdate

vous pouvez en savoir plus à ce sujet dans le docs .

---

En règle générale ne pas utilisercomponentWillMount du tout (si vous utilisez la syntaxe es6 class). utilisez plutôt la méthode constructor.
Cette méthode de cycle de vie est bonne pour une initialisation d'état de synchronisation.
componentDidMount d'autre part est bon pour la manipulation d'état asynchrone.

Pourquoi ?
Eh bien, lorsque vous effectuez une demande asynchrone dans constructor/componentWillMount, vous le faites avant que render soit appelé, au moment où l'opération asynchrone a terminé la La méthode render est probablement déjà terminée et inutile de définir "l'état initial" à ce stade, n'est-ce pas?.
Je ne suis pas sûr que ce soit votre cas ici, mais la plupart des cas que les développeurs souhaitent initier de manière asynchrone dans componentWillMount consistent à éviter un deuxième appel render. mais vous ne pouvez pas l'éviter, comme mentionné ci-dessus, render se déclenchera de toute façon avant la fin de l'opération asynchrone.
Ainsi, le meilleur moment pour appeler une opération asynchrone est après l'appel d'un render et le montage du composant (vous pouvez monter null ou un <div/> Vide) puis récupérez vos données, définissez l'état et faites-les re-rendre respectivement.

Answer 3

componentDidMount est le meilleur endroit pour passer des appels pour récupérer des données, pour deux raisons:

1. L'utilisation de componentDidMount indique clairement que les données ne seront chargées qu'après le rendu initial. Vous devez configurer correctement l'état initial afin de ne pas obtenir l'état undefined qui provoque des erreurs.

2. Si vous devez rendre votre application sur le serveur, componentWillMount sera appelé deux fois (sur le serveur et à nouveau sur le client), ce qui n'est probablement pas ce que vous voulez. Mettre le code de chargement des données dans componentDidMount garantira que les données ne seront récupérées que depuis le client. En règle générale, vous ne devez pas ajouter d'effets secondaires à componentWillMount.

Answer 4

D'après ce que je comprends, l'une des principales raisons est liée à définir les bonnes attentes pour les développeurs lire le code.

Si nous utilisons componentWillMount, il est tentant de penser que la récupération a le temps de se produire, alors le composant "a" monté, et puis le le premier rendu se produira. Mais ce n'est pas le cas. Si nous faisons un appel asynchrone (comme un appel API avec Promises), le composant exécutera réellement render avant que la récupération puisse retourner et définir l'état du composant (ou changer l'état Redux, ou quoi que ce soit).

Si nous utilisons à la place componentDidMount, il est clair que le composant sera rendu au moins une fois avant que vous ne récupériez les données (car le composant ( l'a déjà fait montage). Donc, par extension, il est également clair que nous devons gérer l'état initial de manière à ce que le composant ne se casse pas lors du premier rendu ("vide").

Answer 5

Le cycle de vie du montage des composants est

• constructeur()
• componentWillMount ()/UNSAFE_componentWillMount () (réagir 16)
• rendre()
• componentDidMount ()

Le constructeur et componentWillMount appellent tous les deux avant l'appel de render () qui est responsable de rendu de page.

Ici, l'état initialisé se fait dans le constructeur et les api sont appelées dans componentDidMount en raison d'appels asynchrones.

ComponentWillMount était bon à l'état initialisé avant ES6 lorsque le constructeur n'était pas là. Mais maintenant ComponentWillMount n'est bon à rien et l'équipe de Rea y réfléchit après avoir réagi 17.

De plus à ci-dessus, react s'est déplacé pour réagir architecture fibre , pour éviter un nouveau rendu inutile et améliorer les performances, react a a décidé de s'éloigner des méthodes componentWillMount, componentWillReciveProps et componentWillUpdate.