En los documentos de reacción, recomienda realizar solicitudes de red iniciales en el método componentDidMount :
componentDidMount()se invoca inmediatamente después de montar un componente. La inicialización que requiere nodos DOM debe ir aquí. Si necesita cargar datos desde un extremo remoto, este es un buen lugar para instanciar la solicitud de red. Establecer el estado en este método activará una nueva representación.
Si se llama a componentWillMount antes de representar el componente, ¿no es mejor realizar la solicitud y establecer el estado aquí? Si lo hago en componentDidMount , se procesa el componente, se realiza la solicitud, se cambia el estado y luego se vuelve a procesar el componente. ¿Por qué no es mejor hacer la solicitud antes de que se rinda algo?
Debe hacer solicitudes en componentDidMount .
Si se llama a componentWillMount antes de representar el componente, ¿no es mejor realizar la solicitud y establecer el estado aquí?
No, porque la solicitud no finalizará en el momento en que se represente el componente de todos modos.
Si lo hago en componentDidMount, el componente se procesa, se realiza la solicitud, se cambia el estado y luego se vuelve a procesar el componente. ¿Por qué no es mejor hacer la solicitud antes de que se rinda algo?
Porque cualquier solicitud de red es asíncrona . De todos modos, no puede evitar un segundo procesamiento a menos que almacene en caché los datos (y en este caso no necesitaría activar la solicitud en absoluto). No puede evitar un segundo render disparándolo antes. No ayudará.
En versiones futuras de React, esperamos que el componentWillMount se active más de una vez en algunos casos, por lo que debe usar el componentDidMount para las solicitudes de red .
Deberías usar componentDidMount .
¿Por qué no es mejor hacer la solicitud antes de que se rinda algo?
Porque:
componentWillMount también se llama durante la representación del lado del servidor (si corresponde) Sin embargo, si tuviera que preguntar, ¿no es mejor iniciar una solicitud en componentWillMount (sin manejarlo realmente en su lugar), definitivamente diría que sí (ES6), y lo hago yo mismo para reducir ocasionalmente algunos milisegundos de carga veces:
componentWillMount() { // if window && window.XMLHttpRequest if (!this.requestPromise) { this.requestPromise = new Promise(resolve => { // ... perform request here, then call resolve() when done. }); } } componentDidMount() { this.requestPromise.then(data => ...); } Esto comenzará a precargar su solicitud durante el componentWillMount , pero la solicitud solo se maneja en el componentDidMount , ya sea que ya haya terminado para entonces o que aún esté en progreso.
Debe realizar la solicitud en componentDidMount, ya que no se deben realizar solicitudes de efectos secundarios en componentWillMount. Está bien establecer el estado en el componente WillMount, si establece el estado en el componente DidMount, activará inmediatamente un segundo renderizado.
Leerás que es un antipatrón (UGHHH) y algunos linters lo tienen prohibido (eslint-react-plugin), pero no le prestaría mucha atención a eso, ya que a veces es la única forma de interactuar con el DOM. Puede establecer su estado predeterminado en willMount o como una propiedad de método ( state = { } ), si está utilizando la etapa de babel asociada
Como dice, el componente ya se procesará una vez, pero esto es bueno porque puede mostrar algún tipo de cargador o cualquier otra forma de información que se está cargando un recurso.
class MyComp extends Component { // What I do with stage 0 state = { mystate: 1 } // What you might want to do if you're not // on the experimental stage, no need to do // the whole constructor boilerplate componentWillMount() { this.setState({ mystate: 1 }); } componentDidMount() { dispatch(yourAction()); // It's fine to setState here if you need to access // the rendered DOM, or alternatively you can use the ref // functions } render() { if (!this.props.myCollection) return <Loader /> return ( <div> // your data are loaded </div> ) } }