Comprender el patrón de flujo

En realidad estoy estudiando el patrón de flujo y hay algo que no puedo entender con respecto a las tiendas .

¿Qué son exactamente?

He leído muchos artículos, y parece que se trata del dominio.

¿Significa que esta es la parte "abstracta" relacionada con las llamadas de API o las llamadas de back-end?

No está muy claro para mí.

Editar: ¿Podría ser lo mismo que la fábrica angular? ¿Obtener datos remotos, realizar una tarea comercial o almacenar algunos estados de la aplicación (usuario actual conectado, por ejemplo)?

Ok déjame explicarte paso a paso

1 ¿Qué es Flux?

• Un patrón
• Despachador centralizado
• Flujos de datos unidireccionales
• Elemento de la lista

También lo llaman Flux por una razón.

Implementaciones de flujo

• Flujo de Facebook
• Alt
• Reflujo
• Confundir
• NuclearJS
• Fluxible

Una charla con flux

Reaccionar : Hola Acción, alguien hizo clic en el botón "Guardar curso".

Acción : ¡Gracias Reaccionar! Registré un creador de acciones con el despachador, por lo que el despachador debería encargarse de notificar a todas las tiendas que se preocupan.

Despachador : Déjame ver a quién le importa que se guarde un curso. Ah! Parece que la tienda ha registrado una devolución de llamada conmigo, así que se lo haré saber.

Tienda : Hola despachador! ¡Gracias por la actualización! Actualizaré mis datos con la carga útil que envió. Luego emitiré un evento para los componentes React que se preocupan.

Reaccionar : ¡Ooo! Nuevos datos brillantes de la tienda! ¡Actualizaré la interfaz de usuario para reflejar esto!

API de flujo

registrarse (devolución de llamada de función) - “Hola despachador, ejecútame cuando sucedan acciones. -Tienda"

anular el registro (id. de cadena) : “Hola despachador, deja de preocuparte por esta acción. -Tienda"

waitFor (array ids) : “Actualice esta tienda primero. -Tienda"

dispatch (objeto de carga útil) - “Hola despachador, cuéntales a las tiendas sobre esta acción. -Acción"

isDispatching () - "Estoy ocupado enviando devoluciones de llamada en este momento".

así que la pregunta que surge en nuestra mente es

Entonces, ¿Flux es un modelo de publicación-suscripción?

No exactamente.

Se diferencia de dos maneras:

1. Cada carga útil se envía a todas las devoluciones de llamada registradas.

2. Las devoluciones de llamada pueden esperar otras devoluciones de llamada

Resumen

Flux es un patrón para flujos de datos unidireccionales. Acciones encapsulan eventos. Dispatcher es un centro central que contiene devoluciones de llamada. Las tiendas mantienen el estado de la aplicación. Muchas implementaciones

Buscando un ejemplo simple ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), "las tiendas administran el estado de la aplicación para un dominio particular dentro de la aplicación". Es decir, contienen datos sobre el estado de un aspecto de la aplicación y todo el código para cambiarlo. Cada vez que hay una nueva actualización del Despachador, todas las Tiendas lo ven, deciden cómo actualizar sus datos en respuesta y luego notifican a las Vistas que los datos han cambiado. En los ejemplos, las Tiendas contienen cosas como "lista de hilos no vistos" (donde el Despachador les notifica que ha llegado un nuevo mensaje o que se ha leído uno antiguo, y las Vistas muestran los hilos del mensaje al usuario) y "Tiempo de reproducción actual y estado."

Más técnicamente: son la capa intermedia del marco que registra devoluciones de llamada con el Despachador para recibir actualizaciones, luego notifica a las Vistas cuando cambia el estado de los datos. (Las vistas pueden enviar acciones al Dispatcher). Hay una interfaz abstracta que implementan, donde cada Tienda registra una devolución de llamada con el Despachador y transmite eventos a las Vistas, pero cada Tienda parece representar un dominio específico de una manera concreta. (¿Hay contraejemplos?)

Las tiendas son áreas del código que almacenan el estado de la aplicación y la lógica compleja. Una razón para ellos es que las vistas múltiples probablemente usarán los mismos datos, pero los mostrarán de una manera diferente, o mostrarán algunos pero no todos los datos de un dominio particular. Por ejemplo, un usuario inicia sesión y usted recibe su nombre, apellido, correo electrónico, foto, ciudad, número de dirección, número de teléfono, etc. Esta información se muestra en vistas separadas. En lugar de duplicar datos en las vistas, podemos usar una tienda llamada UserStore que almacena los datos para el usuario. Esto simplifica el sistema al dar "un lugar para hacer un cambio" siempre que la lógica o los datos almacenados deben cambiarse. Hay muchas otras razones para usar una Tienda, sin embargo, esa es la más obvia, creo.