Estoy usando withReducer HOC y noté este comportamiento: llamar a esto en el controlador de clics, por ejemplo:
import React from 'react' import { withReducer } from 'recompose' import { compose } from 'ramda' export default compose( withReducer('state', 'dispatch', (state, { value }) => { console.log(value) return { ...state, value } }, { value: 'zero' }) )((props) => { const { dispatch, state } = props, onClick = () => { console.log('Hello') dispatch({ value: 'one' }) dispatch({ value: 'two' }) dispatch({ value: 'three' }) console.log('World') } return ( <div> <div>{state.value}</div> <button onClick={onClick}>Click me</button> </div> ) })producirá
Hola
Mundo
uno
dos
Tres
Esto significa que la función de reducción se llama de forma asincrónica. ¿Cuál es la justificación para llamarlo asíncrono en lugar de aplicar cambios a la tienda de inmediato?
El reductor se llama de forma asíncrona porque solo podemos usar setState para actualizar el árbol y setState es asíncrono.
Si llamamos al reductor de forma sincrónica, necesitaremos guardar el nuevo estado en algún lugar, luego llamar a setState y obtener el nuevo estado de forma asíncrona desde donde lo guardamos. Al final, su árbol aún se actualiza de forma asíncrona.
Esta es la razón por la que withReducer() de recompose es ligeramente diferente de redux. Puedes pensar que withReducer es una versión simplificada de redux + react-redux's connect() .
En este caso, dispatch es en realidad un contenedor para el método setState de la API Vanilla.
React implementa setState de forma asíncrona porque las transiciones de estado a veces se agrupan por lotes por motivos de rendimiento.
De acuerdo con los documentos React:
setState() no muta inmediatamente este.estado, sino que crea una transición de estado pendiente... No hay garantía de funcionamiento síncrono de las llamadas a setState y las llamadas pueden agruparse para mejorar el rendimiento.