Las principales características de la arquitectura de estilo flux son aproximadamente las siguientes:

1. la tienda es la única fuente de verdad para el estado de la aplicación
2. solo las acciones pueden desencadenar la mutación del estado de la tienda
3. el estado de la tienda no debe mutarse directamente, es decir, mediante la asignación de valores de objeto, sino mediante la creación de nuevos objetos mediante la clonación/desestructuración en su lugar

Al igual que una dieta, el uso de este tipo de arquitectura realmente no funciona si fallas y vuelves a las viejas formas de forma intermitente.

Volviendo a tu ejemplo. El beneficio de usar la acción aquí no es la transmisión o el registro de aspectos, sino simplemente el hecho de que la clase People solo debería poder consumir datos de una tienda y expresar sus deseos de mutar el estado de dicha tienda con acciones. Imagina, por ejemplo, que los Elves quieren cantarle al ogro y, por lo tanto, están interesados en saber que dicho ogro todavía está vivo. Al mismo tiempo, la People quiere ser cortés y no quiere matar al ogro mientras le dan una serenata. Los beneficios de la arquitectura de estilo flux son claros:

 class People { kill(creature) { if (creatureStore.getSerenadedCreature() !== creature) store.dispatch({ type: 'KILL', payload: { target: creature } }) return `The ${creature} is being serenaded by those damn elves, let's wait until they've finished.` } } class Elves { singTo(creature) { if (!creatureStore.getCreatures().includes(creature)) return store.dispatch({ type: 'SING_TO', payload: { target: creature } }) return `Oh no, the ${creature} has been killed... I guess there will be no serenading tonight..` } }

Si la clase People fuera a envolver la tienda, necesitaría la clase Elves para envolver la misma tienda también, creando dos lugares donde el mismo estado sería mutado de una forma u otra. Ahora imagine si hubiera otras 10 clases que necesitan acceso a esa tienda y quieren cambiarla: agregar esas nuevas características se está convirtiendo en una molestia porque todas esas clases ahora están a merced de las otras clases mutando el estado debajo de ellas, obligándolo para manejar toneladas de casos extremos que posiblemente ni siquiera estén relacionados con la lógica comercial de esas clases.

Con la arquitectura de estilo flux, todas esas clases solo consumirán datos de la tienda de creatureStore y enviarán acciones basadas en ese estado. La tienda maneja la conciliación de las diferentes acciones con el estado para que todos sus suscriptores tengan los datos correctos en los momentos correctos.

Los beneficios de este patrón pueden no ser evidentes cuando solo tiene un par de tiendas que son consumidas por una o dos entidades cada una. Cuando tiene decenas (o cientos) de tiendas con decenas (o cientos) de componentes que consumen datos de varias tiendas cada uno, esta arquitectura le ahorra tiempo y dinero al facilitar el desarrollo de nuevas funciones sin romper las existentes.

¡Espero que este wall-o-text haya ayudado a aclarar!

Lo que no veo es cómo poner las acciones en forma de objetos JSON, de repente refuerza o ayuda con el flujo de comunicación "unidireccional", que es lo que leo en todas partes, es la gran ventaja de tener acciones y de flujo. Me parece que todavía estoy enviando un mensaje a la tienda, sin importar cómo perfume al cerdo. Claro, la acción ahora pasa por un par de capas de direccionamiento indirecto (creador de acción, despachador) antes de llegar a la tienda, pero a menos que me falte algo, el componente que envía esa acción para todos los propósitos prácticos está actualizando las tiendas que están escuchando para el matar mensaje ¿Qué me estoy perdiendo aquí?

Facebook Flux tomó la idea de los sistemas GUI basados en eventos. Allí, incluso si mueves el mouse, recibes mensajes. Esto se llamaba bucle de mensajes entonces, y ahora tenemos despacho de acciones.

Además, tenemos listas de suscriptores dentro de las tiendas.

Y es realmente el mismo principio en Redux donde tienes una tienda, mientras que en Flux puedes tener varias tiendas.

Ahora un poco de matemáticas. Al tener 2 componentes A y B, necesita tener solo unas pocas cadenas de actualización posibles A, actualizaciones B y B, actualización A, o actualización automática (sin incluir aquí las actualizaciones desde fuera de la aplicación). Este es el caso posible.

Con solo tres componentes tenemos muchas más cadenas posibles.

Y con aún más componentes se complica. Entonces, para suprimir la complejidad exponencial de la posible interacción de los componentes, tenemos este patrón Flux que en nada más que IDispatch , IObservable si trabajó con estas interfaces de otros lenguajes de programación. Una sería para escupir las acciones, y la otra para entrar en la cadena de oyentes que existe dentro de la tienda.

Con este patrón, su código React se organizará de una manera diferente al enfoque común de React. Ya no tendrá que usar el estado React.Component . En su lugar, utilizará las tiendas que mantendrán el estado de la aplicación.

Su componente solo puede mostrar el deseo de mutar el estado de la aplicación al enviar la acción. Por ejemplo: onClick puede enviar la acción para incrementar el contador. Las acciones son objetos con el type: que suele ser una cadena, y normalmente en mayúsculas, pero el objeto de acción puede tener muchos otros accesorios como ID, valor,...

Dado que los componentes son responsables de la representación en función del estado de la aplicación, necesitamos entregarles de alguna manera el estado de la aplicación . Puede ser a través de props = store.getState() o podemos usar context . Pero también revisa esto .

Finalmente, ni siquiera está prohibido que el componente use el estado interno (this.state) en caso de que esto no tenga impacto en la aplicación. Debes reconocer estos casos.