Discover Functional JavaScript fue nombrado uno de los mejores libros nuevos de programación funcional por BookAuthority .
Flux es un patrón arquitectónico propuesto por Facebook para construir SPA. Sugiere dividir la aplicación en las siguientes partes:
- Historias
- Despachador
- Puntos de vista
- Creadores de acción / acción
Tienda
La tienda gestiona el estado. Puede almacenar tanto el estado del dominio como el estado de la interfaz de usuario.
Tienda y estado son conceptos diferentes. El estado es el valor de los datos. Store es un objeto de comportamiento que gestiona el estado mediante métodos. En el caso de la gestión de libros: la lista de libros es el estado y BookStore gestiona esa lista.
Una tienda gestiona varios objetos. Es la única fuente de verdad con respecto a esos objetos específicos. En una aplicación puede haber muchas tiendas. Por ejemplo: BookStore, AuthorStore, UserStore.
No hay métodos de establecimiento en la tienda. Solo puede solicitar un cambio de estado pasando una acción al despachador.
Una tienda escucha todas las acciones y decide cuál de ellas actuar. Esto generalmente significa una switchdeclaración. Una vez que la tienda haya realizado los cambios de estado, emitirá un evento de cambio. La tienda es un emisor de eventos.
Las tiendas no toman otras tiendas como dependencias.
Despachador
Dispatcher es un objeto único que transmite acciones / eventos a todas las tiendas registradas. Las tiendas deben registrarse para eventos cuando se inicia la aplicación.
Cuando entra una acción, pasará esa acción a todas las tiendas registradas.
Ver
View es el componente de la interfaz de usuario. Es responsable de representar la interfaz de usuario y de manejar la interacción del usuario. Las vistas están en una estructura de árbol.
Las vistas escuchan los cambios de la tienda y vuelven a renderizar.
Las vistas se pueden dividir aún más en vistas de presentación y contenedor.
Las vistas de presentación no se conectan al despachador ni a las tiendas. Se comunican solo a través de sus propias propiedades.
Las vistas de contenedores están conectadas a las tiendas y al despachador. Escuchan eventos de las tiendas y proporcionan los datos para los componentes de presentación. Obtienen los nuevos datos utilizando los métodos de obtención públicos de las tiendas y luego pasan esos datos al árbol de vistas.
El contenedor ve acciones de despacho en respuesta a la iteración del usuario.
Comportamiento
Una acción es un objeto simple que contiene toda la información necesaria para realizar esa acción.
Las acciones tienen una typepropiedad que identifica el tipo de acción.
A medida que los objetos de acción se mueven por la aplicación, sugiero que sean inmutables.
Las acciones pueden provenir de diferentes lugares. Pueden provenir de vistas como resultado de la interacción del usuario. Pueden provenir de otros lugares, como el código de inicialización, donde se pueden tomar datos de una API web y se activan acciones para actualizar las vistas. La acción puede provenir de un temporizador que requiere actualizaciones de pantalla.
Creadores de acciones
La práctica consiste en encapsular el código, creando acciones en funciones. Estas funciones que crean y envían acciones se denominan creadores de acciones.
Llamadas a API web
Al realizar llamadas a la API web para actualizar la interfaz de usuario, la llamada a la API web será seguida por una acción para actualizar la tienda. Cuando la tienda se actualice, emitirá un evento de cambio y, como resultado, la vista que escucha ese evento se volverá a representar.
Las llamadas a la API web se realizan en creadores de acciones. Podemos extraer el código que realiza la llamada a la API en las funciones de Web API Utils.
Flujo de datos unidireccional
La actualización de las vistas fluye en una sola dirección:
Las vistas no modifican los datos que recibieron. Escuchan los cambios de estos datos, crean acciones con nuevos valores, pero no actualizan los datos.
Las tiendas, las vistas y cualquier otra acción no pueden cambiar el estado en (otras) tiendas directamente. Deben enviar una acción a través del despachador.
El flujo de datos es más corto en las lecturas de la tienda que en las escrituras. El flujo de datos en las escrituras de la tienda difiere entre las acciones asíncronas y sincrónicas.
Lecturas de tienda
Almacenar escribe en acciones sincrónicas
Store escribe en acciones asincrónicas
Pros
La arquitectura de flujo es mejor en una aplicación donde las vistas no se asignan directamente a las tiendas de dominios. Para decirlo de otra manera, cuando las vistas pueden crear acciones que actualizarán muchas tiendas y las tiendas pueden desencadenar cambios que actualizarán muchas vistas.
Las acciones se pueden conservar y luego reproducir.
Contras
Flux puede agregar complejidad innecesaria a una aplicación donde cada vista se asigna a una tienda. En este tipo de aplicación es suficiente una separación entre vista y almacenamiento.
Eche un vistazo, por ejemplo, a Cómo crear una aplicación de tres capas con React.
Conclusión
Las tiendas administran el estado. Cambian de estado solo escuchando acciones. Las tiendas notifican las vistas para actualizarlas.
Las vistas representan la interfaz de usuario y manejan la interacción del usuario. Las vistas de contenedor escuchan los cambios de tienda.
El despachador transmite acciones a todas las tiendas registradas.
Las acciones son objetos simples.
Discover Functional JavaScript fue nombrado uno de los¡Los mejores libros nuevos de programación funcional de BookAuthority !
Para obtener más información sobre la aplicación de técnicas de programación funcional en React, eche un vistazo a Functional React .
Aprenda React funcional , de una manera basada en proyectos, con Arquitectura funcional con React y Redux .
Seguir en Twitter