Recabamos por distintos sitios y así brindarte la solución para tu duda, si tienes dificultades puedes dejar tu duda y te contestaremos con mucho gusto, porque estamos para servirte.
Solución:
No se supone que Redux “reemplace la idea inicial de react.js”, considérelo más como una biblioteca para administrar el estado compartido entre los componentes y coordinar las mutaciones de estado. Redux usa un patrón pub/sub de hecho, vea los métodos de tienda aquí: http://redux.js.org/docs/api/Store.html#store-methods Encontrará un subscribe método que utilizan los componentes para suscribirse a los cambios en el árbol de estado. Normalmente, no usa store.subscribe directamente, ya que los enlaces Redux-React (Redux connect básicamente) hacer eso por ti. Puede consultar la implementación real aquí, no es tan complicado de seguir (de hecho, para mí, ese es el principal beneficio de Redux sobre otras implementaciones de Flux): https://github.com/reduxjs/react-redux/blob/4. x/src/components/connect.js#L199
Ese código, además de suscribirse a los cambios emitidos por la tienda, también realiza algunas optimizaciones, como pasar nuevos accesorios al componente (y, por lo tanto, activar una nueva representación) solo cuando es realmente necesario.
Considere también que está perfectamente bien seguir usando el estado interno de los componentes junto con Redux. Puede usar el estado interno para almacenar el estado que no necesita/quiere compartir con otros componentes.
Ves la necesidad de algo como Redux cuando tienes una aplicación más complicada, con componentes de nivel superior que necesitan comunicarse entre sí (acciones) y de alguna manera compartir algún estado.
Las acciones en Redux son, de forma predeterminada, POJO (objetos de javascript simples y antiguos), puede considerarlos como “eventos” que a menudo envía en respuesta a acciones desencadenadas por el usuario (por ejemplo, el usuario hizo clic en un botón), pero no está limitado. a eso, puedes enviar una acción desde donde quieras. La tienda Redux escucha estas acciones y llama a los reductores (funciones puras) pasando el objeto de acción que envió.
Los reductores interceptan todas las acciones enviadas y pueden devolver un estado nuevo y actualizado para el segmento de estado que administran.
En este sentido, un reductor es una función que procesa las acciones y actualiza el estado según sea necesario.
A su vez, cuando un reductor actualiza el estado devolviendo una nueva copia del estado, a los componentes conectados (suscritos a los cambios en el estado) se les pasarán nuevas propiedades y se volverán a representar para reflejar los cambios.
A veces, enviar objetos js simples no es suficiente y necesita más control. Eso queda claro cuando necesita realizar una lógica más complicada, por ejemplo, cuando necesita actualizar un contador en el estado según la respuesta de una llamada AJAX.
Con redux-thunk puede enviar funciones en lugar de solo objetos simples. Al enviar una función, está implementando efectivamente la inversión del patrón de control de una manera muy simple. Su acción se convierte en una “receta” descrita por la función, y no solo en una declaración simple, como con una acción POJO.
¿Por qué solo los POJO son compatibles “listos para usar”, para acciones, por qué no hay una clase de acción base o algo así? Principalmente porque no hay necesidad de eso. Un objeto simple (considerado como una bolsa de valores básicamente) con un type property es todo lo que realmente necesita, es básicamente la interfaz más simple posible. Puede considerar que esto es una programación contra una interfaz (la acción) en lugar de una implementación.
¿Por qué es mejor un estado global, en lugar de que cada componente maneje su propio estado? Principalmente porque administrar el estado es en realidad la parte más difícil de una aplicación js no trivial. Al usar Redux, extrae toda esa lógica de la capa de la interfaz de usuario, lo que facilita la prueba. De hecho, idealmente debería poder probar toda la “lógica comercial” real de una aplicación Redux sin siquiera renderizar un solo componente.
Los componentes se vuelven “más tontos” y “más puros”, ya que solo representan lo que se les dice que hagan. “Más puro” aquí significa que debido a que no tienen ningún estado, lo que ve renderizado solo depende de las entradas (léase “accesorios”) en cualquier momento dado, y no por ningún historial, por lo tanto, “sin estado”.
Tener el estado como un único objeto json serializable también facilita la depuración, la instantánea y el envío/restauración desde un servidor o almacenamiento local.
No puedo votar la respuesta de Fabios dos veces y la sección de comentarios es demasiado pequeña:
Sí, en mi opinión, es como un pub/sub con una convención.
Para ilustrar cómo la transmisión de accesorios puede ser una molestia, he aquí un ejemplo.
Supongamos que tiene un componente que muestra el usuario que ha iniciado sesión actualmente. La jerarquía de sus componentes es como un árbol enorme. Ahora, si mostrara ese componente en una rama que comienza en la raíz y en otra rama que también comienza en la raíz, cada uno en lo más profundo de la jerarquía, tendría que pasar la información del usuario desde el componente raíz a los nodos de hoja en 2 caminos diferentes, contaminando los accesorios de todos los componentes en el camino (que no están relacionados en absoluto con la información del usuario, pero ahora necesitan saber).
No se te olvide mostrar esta noticia si te fue útil.