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

Closed
jhades opened this Issue Jan 6, 2016 · 7 comments

Comments

Projects
None yet
7 participants
@jhades

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!

@petehunt

This comment has been minimized.

Show comment
Hide comment
@petehunt

petehunt Jan 7, 2016

Owner

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?

Owner

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?

@jhades

This comment has been minimized.

Show comment
Hide comment
@jhades

jhades Jan 7, 2016

Thanks for the reply, I think its clear now.

jhades commented Jan 7, 2016

Thanks for the reply, I think its clear now.

@jhades jhades closed this Jan 7, 2016

@sboselli

This comment has been minimized.

Show comment
Hide comment
@sboselli

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

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

@svenanders

This comment has been minimized.

Show comment
Hide comment
@svenanders

svenanders Jan 7, 2016

Games is an awesome example. :)

Games is an awesome example. :)

@krasimir

This comment has been minimized.

Show comment
Hide comment
@krasimir

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

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.

@fingermark

This comment has been minimized.

Show comment
Hide comment
@fingermark

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

@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

This comment has been minimized.

Show comment
Hide comment
@zeeshanjan82

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

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