reactjs - example - ¿Por qué usar getDerivedStateFromProps en lugar de componentDidUpdate?

react getderivedstatefromprops

Question

Como leí en este número de React Github, veo más y más que

El costo de render() es relativamente pequeño.

En React 16.3 , me pregunto por qué uno usaría el nuevo getDerivedStateFromProps en lugar de componentDidUpdate?

Imagina este ejemplo:

getDerivedStateFromProps(nextProps, prevState) {
if (!prevState.isModalOpen && nextProps.isReady) {
return { isModalOpen: true };
}
}

versus

componentDidUpdate(prevProps, prevState) {
if (!prevState.isModalOpen && this.props.isReady) {
this.setState({ isModalOpen: true });
}
}

Lo último parece más sencillo simplemente porque usa solo la API existente y se parece a lo que solíamos hacer en componentWillReceiveProps, así que no veo por qué los usuarios irían por getDerivedStateFromProps? ¿Cuál es el beneficio?

¡Gracias!

Answer 1

Entonces Dan Abramov respondió en Twitter y parece que hay dos razones por las que deberías usar getDerivedStateFromProps lugar de componentDidUpdate + setState :

setState en componentDidUpdate causa un procesamiento adicional (no perceptible directamente por el usuario pero ralentiza su aplicación). Y el método de renderización no puede asumir que el estado está listo (porque no será la primera vez).

• Motivo de las interpretaciones: evita repeticiones innecesarias.
• Como se llama a getDerivedStateFromProps antes de renderizar en init, puede inicializar su estado en esta función en lugar de tener un constructor para hacerlo. Actualmente tenía que tener un constructor o un componentWillMount WillMount para iniciar su estado antes de la representación inicial.

Answer 2

getDerivedStateFromProps es en realidad un reemplazo para componentWillReceiveProps y componentDidMount no va a estar en desuso.

Estoy bastante seguro de que fue la comunidad la que decidió crear un método estático con ese nombre.

El motivo de este cambio es que componentWillReceiveProps fue uno de los métodos que generó confusión y más pérdidas de memoria en las aplicaciones de usuario :

Muchos de estos problemas se ven agravados por un subconjunto de los ciclos de vida de los componentes (componentWillMount, componentWillReceiveProps y componentWillUpdate). Estos también son los ciclos de vida que causan la mayor confusión dentro de la comunidad React. Por estas razones, vamos a desaprobar esos métodos en favor de mejores alternativas.

Aquí está el tweet de Dan Abramov que también lo hace más claro:

Sin embargo, esto significa que separaremos nuestros caminos con componentWillReceiveProps () en 17. Creemos que getDerivedStateFromProps () hace el mismo trabajo mejor y es menos confuso. También sucede que cWRP () realmente arruina nuestros planes para características de recuperación de datos que podrían estar en trámite. 🙂