Clearer instructions on when to use or not use Flux

[jhades]

I looked around and could not find an offical source of recomendations of when to use or not Flux, other than what you mention. Maybe its in a talk and its not indexable ? I think Flux is likelly being used in situations where just bringing plain DTOs from the backend and binding them to a template and render is all that is needed.

I think it would be huge if it was be clearer what are the tradeoffs of Flux and when to use it, what are the gains, Does it make sense to use it in a mostly read only dashboard / monitoring charts application, if the data is only shown at one place?

I suggest if its mentioned in a talk can you link it here so that its easily googleable, if not a brief reply in this issue would be great. Wouldnt dare ask for a blog post as i know you are busy with your startup. Thanks for Flux!

[petehunt]

I think the use of flux is justified when two conditions are met:

1. You have a piece of data that needs to be used in multiple places in your app, and passing it via props makes your components break the single-responsibility principle (i.e. makes their interface make less sense)
2. There are multiple independent actors (generally, the server and the end-user) that may mutate that data.

Stores solve the first problem (as do single state atoms and event emitters), a serializable action queue solves the second.

Does this make sense? Do you disagree?

[jhades]

Thanks for the reply, I think its clear now.

[sboselli]

I think another very valid use case for Flux Redux is for applications where you would want to be able to save/reproduce the full action history. Games for example, are a good match that could benefit greatly (replay games, action history as seed/solution to a level, etc).

[robbestad]

Games is an awesome example. :)

[krasimir]

I think the power of flux is the fact that manages complexity very well. The one direction data flow is something really important and that pattern (flux) embrace it. I wouldn't use flux where I have less complexity. If for example we have a static page with a single contact form at the end. There is nothing much happening so maybe we don't need stores and actions. We do may need flux if there are couple of contact forms and they have to exchange data.

The truth is that flux is really simple pattern and as such is easy to plug it in almost everywhere. Most of the flux implementation available out there are approx ~2K.

[fingermark]

@petehunt , you have a section for learning flux and learning relay. It's still not clear to me why relay is only a solution for only handling remote state and also mutually exclusive with flux (as it therefore seems incomplete) -- or am I wrong. Most of my apps have pieces of local data that are used in multiple locations, and often dictate how the main component loads remote data. Are relay and flux/redux truly mutually exclusive?

[zeeshanjan82]

I have spend few days with Redux and knowing flux architecture, I liked its way of event driver architecture which I think is very exciting as you have events which fire like actions and they get caught and are handled by the state change happening, there have been various instances where I am inside one component and would like to update other components on the screen, I think Redux or Flux architecture provides a better way to manage all that complexity.