Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clearer instructions on when to use or not use Flux #12

jhades opened this issue Jan 6, 2016 · 7 comments

Clearer instructions on when to use or not use Flux #12

jhades opened this issue Jan 6, 2016 · 7 comments


Copy link

jhades commented Jan 6, 2016

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!

Copy link

petehunt commented Jan 7, 2016

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?

Copy link

jhades commented Jan 7, 2016

Thanks for the reply, I think its clear now.

@jhades jhades closed this as completed Jan 7, 2016
Copy link

sboselli commented Jan 7, 2016

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).

Copy link

robbestad commented Jan 7, 2016

Games is an awesome example. :)

Copy link

krasimir commented Jan 7, 2016

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.

Copy link

fingermark commented Jan 11, 2016

@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?

Copy link

zeeshanjan82 commented Jun 15, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

7 participants