Componentes de flujo de arquitectura de JavaScript

Flux: es una arquitectura o patrón de JavaScript para UI que se ejecuta en un flujo de datos unidireccional y tiene un despachador centralizado. Es una arquitectura de aplicación diseñada para crear aplicaciones web del lado del cliente. También es una de las arquitecturas populares que utiliza Facebook para crear aplicaciones web del lado del cliente. La arquitectura Flux se basa en los siguientes componentes.

Cuatro componentes principales de Flux:

1. Despachador: Coordina acciones y actualizaciones a las tiendas.
2. Tiendas: sirve como contenedor para el estado y la lógica de la aplicación.
3. Acciones: Habilita el paso de datos al despachador
4. Vistas: Es lo mismo que la vista en la arquitectura MVC pero en el contexto de los componentes de React.

Con palabras simples, si entendemos el todo, entonces en la arquitectura Flux básicamente supongamos que un usuario hace clic en algo, la vista crea acciones; Las acciones crean nuevos datos y los envían al despachador, aquí viene el trabajo del despachador, el despachador envía los resultados de la acción a la tienda correspondiente. Luego, la tienda actualiza el estado que se basa en el resultado y envía una actualización a la vista.

Los datos en una aplicación de flujo fluyen en una sola dirección, o podemos decir que los datos en una aplicación de flujo fluyen en un flujo unidireccional, la importancia del flujo unidireccional es que, dado que los datos fluyen a través de su aplicación en una sola dirección, podemos tener un mejor control sobre eso.

Caudal:

Action => Dispatcher => Store => View

Despachador:

El despachador es el eje central que gestiona todo el flujo de datos en una aplicación de flujo, esencialmente un registro de devoluciones de llamada a las tiendas que no tiene inteligencia propia, o podemos decir que es un mecanismo simple para distribuir las acciones a las tiendas.

• Es el epicentro del flujo de datos en cualquier aplicación Flux
• Controla lo que fluye hacia las tiendas de la aplicación Flux.
• Sirve como lugar de alojamiento para las devoluciones de llamada que crean las tiendas y que están vinculadas al despachador.
• Cada tienda en la aplicación crea una devolución de llamada que la registra con el despachador.
• Cuando un creador de acciones envía una nueva acción al despachador, el despachador se asegura de que, debido a la devolución de llamada, todas las tiendas registradas obtengan esa acción.

Nota: El despachador es el árbitro final de las dependencias de datos.

La arquitectura Flux es útil para acciones que incluyeron los efectos de aclarar el código, actualizar otras vistas y depurar por nuevos desarrolladores. También incluye un despachador singleton y todas las acciones pasan por el despachador. Este diseño defiende actualizaciones en cascada difíciles de depurar.

Historias:

La tienda es el centro del estado y la lógica de la aplicación, la función es similar a un modelo en un MVC tradicional. Se registra con el despachador y le proporciona una devolución de llamada, y este recibe acción como parámetro.

• Contiene la lógica y el estado de la aplicación Flux.
• En lugar de representar una única estructura de datos como un modelo tradicional, la tienda en Flux puede representar el estado de gestión de muchos objetos.
• Se registra con un despachador y le proporciona una devolución de llamada.
• La devolución de llamada pasó a tener un parámetro que se conoce como la acción, que se le pasó a través del despachador.

Nota: Las tiendas son donde vive el estado, y solo las propias tiendas pueden cambiar este estado.

La arquitectura Flux utiliza Stores para almacenar en caché cualquier aplicación asociada con datos o estado. Incluye varias tiendas. También tiene capacidades de manejo lógico y flexibilidad para decidir qué partes de sus datos mostrar públicamente.

Comportamiento:

Cuando el despachador expone un método que nos permite activar un envío a las tiendas e incluir una carga útil de datos, que llamamos acción. Las acciones también pueden provenir de otros lugares, como servidores, por ejemplo, tipos de datos durante la inicialización o cuando el servidor devuelve un código de error o cuando los servidores tienen actualizaciones para proporcionar a la aplicación.

• Las acciones definen los métodos, que serán llamados por la vista.
• Es el formulario de datos que se ha enviado a las tiendas.
• Los métodos contienen argumentos, que contienen más instrucciones sobre cómo la vista quiere cambiar la tienda.
• La acción es responsable de traducir las llamadas de despacho a eventos; que son comprensibles para las Tiendas.

Nota: Si no es una acción, no puede suceder.

Las acciones en la arquitectura Flux son colecciones de métodos que se llaman dentro o dentro de las vistas para enviar acciones al Dispatcher. Es una de las cargas útiles reales que se entregan a través del despachador. Los conjuntos tipográficos de ejemplo de tipo de acción se utilizan para definir qué acción debe ocurrir y se envían junto con los datos de la acción.

Puntos de vista:

No es una parte técnica de Flux pero, al mismo tiempo, las vistas son obviamente una parte crítica de nuestra aplicación. Se entiende principalmente como la parte de nuestra arquitectura que es responsable de mostrar los datos al usuario. Es la última parada de nuestra arquitectura de flujo de datos. Las vistas existen fuera de Flux, pero están restringidas por la naturaleza unidireccional de Flux.

• Es simplemente la composición de los componentes.
• Es la parte de la arquitectura que es responsable de mostrar los datos al usuario.
• La capa de vista es la capa donde React encaja en esta arquitectura.

Nota: La única forma en que los datos fluyen fuera de una vista es mediante el envío de una acción.

Básicamente, es solo un componente React que escucha los eventos de cambios y recupera el estado de las aplicaciones de las tiendas, por lo tanto, pasa esos datos a sus componentes secundarios.