De hecho, estoy estudiando el patrón de flujo y hay algo que no puedo entender sobre el almacena .
¿Qué son exactamente?
He leído muchos artículos y parece que se trata de dominio.
¿Significa que esta es la parte «abstracta» relacionada con las llamadas api o llamadas backend?
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)?
Comentarios
- Un enlace a lo que usted ' sería útil hablar de ello. ¿Te refieres a este " patrón de flujo "? fluxxor.com/what-is-flux.html
- facebook.github. io / flux / docs / overview.html # content
- Flux no es más que el patrón de publicación / suscripción con la restricción de que todos los datos pasan primero por el despachador. Garantiza que los datos no retrocedan (y causen confusión). Cosas como " Tienda ", " Acción " etc son solo otra forma de decir Componentes del sistema y los datos que se transmiten.
Respuesta
Ok déjame explicarte paso a paso
1 ¿Qué es Flux?
- Un patrón
- Despachador centralizado
- Flujos de datos unidireccionales
- Elemento de lista
También lo llaman Flux por una razón.
Implementaciones de Flux
- Flux de Facebook
- Alt
- Reflujo
- Flummox
- NuclearJS
- Fluxible
Un chat con Flux
Reaccionar : Hey Action, alguien hizo clic en «Guardar Cour se ”.
Acción : ¡Gracias React! He registrado un creador de acciones con el despachador, por lo que el despachador debe encargarse de notificar a todas las tiendas que se preocupan.
Dispatcher : Déjame ver a quién le importa que se guarde un curso. ¡Ah! Parece que Store registró una devolución de llamada conmigo, así que se lo haré saber.
Store : ¡Hola despachador! ¡Gracias por la actualización! Actualizaré mis datos con la carga útil que enviaste. Luego, emitiré un evento para los componentes de React que se preocupen.
React : ¡Ooo! ¡Nuevos datos brillantes de la tienda! ¡Actualizaré la interfaz de usuario para reflejar esto!
API de flujo
registro (devolución de llamada de función) – “Hola despachador, ejecúteme cuando ocurran acciones. -Store ”
unregister (string id) -“ Hola despachador, deje de preocuparse por esta acción. -Store ”
waitFor (array ids) -“ Actualiza primero esta tienda. –Store ”
dispatch (objeto payload) -» Hola despachador, cuéntale a las tiendas sobre esta acción . -Acción ”
isDispatching () -» Estoy ocupado enviando devoluciones de llamada en este momento «.
entonces la pregunta que surge en nuestra mente es
¿Entonces Flux es un modelo de publicación-suscripción?
No exactamente.
Se diferencia de dos formas:
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 Las acciones encapsulan eventos Dispatcher es un centro central que contiene devoluciones de llamada Las tiendas mantienen el estado de la aplicación Muchas implementaciones
Comentarios
- Mi primer problema ¿Ese estado permite que la aplicación tenga diferentes datos de las entidades api remotas: – /
- qué quieres decir con el estado permite? donde sea que se llame a emit change, se llamará React View y nuevamente se llamará método de cambio de estado.
- Admitiendo que construyo una aplicación con flux. Estoy tratando con una API y luego guardo los datos dentro de mis tiendas. ¿Qué pasa si los usuarios modifican los datos remotos? Tendré una diferencia entre el cliente y el servidor
- ahora, ¿dónde puedo encontrar por qué? Si todo lo que el despachador y la tienda van a hacer es reenviar la vista, entonces ¿por qué ' t acción actualizar la vista directamente.por qué hay intermediarios
- @MuhammadUmer: Dispatcher es uno para la aplicación y el almacenamiento se basa en el componente en la aplicación, por lo que para eliminar la redundancia se introdujeron los intermediarios
Respuesta
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 Dispatcher, todas las Tiendas la 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 mensaje nuevo o se ha leído uno antiguo, y las vistas muestran los hilos del mensaje al usuario) y «tiempo de reproducción actual y state. ”
Más técnicamente: son la capa intermedia del marco que registra las devoluciones de llamada con el Dispatcher para recibir actualizaciones, luego notifica a las Vistas cuando cambia el estado de los datos. (Las vistas pueden enviar acciones de regreso al Dispatcher). Existe una interfaz abstracta que implementan, donde cada Tienda registra una devolución de llamada con el Dispatcher y transmite eventos a las Vistas, pero cada Tienda parece representar un dominio específico de una manera concreta. (¿Hay contraejemplos?)
Respuesta
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 es probable que varias vistas usen los mismos datos, pero los muestren de una manera diferente, o muestren algunos pero no todos los datos para un dominio en particular. Por ejemplo, un usuario inicia sesión y 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 del usuario. Esto simplifica el sistema al dar «un lugar para hacer un cambio» cada vez que la lógica o los datos almacenados deben cambiarse. Hay muchas otras razones para usar una Tienda, sin embargo, creo que esa es la más obvia.