6 ms·

Redux: Atomic Flux with Hot Reloading

186 points by monort 11y ago

anon3_ 11y ago
To begin, I'm not quite sure what flux is. https://github.com/facebook/flux https://github.com/facebook/flux is this the flux it's for? It seems opaque to me at this stage. It reminds me of when Google released Polymer. There was a lot of generic stuff - but no elevator pitch. Explain to me in 30 seconds what's flux and where it sits?
- skrebbel 11y ago
  Flux is two things: a library by facebook (which you linked to), and a set of vaguely specified ideas. It's the second definition this article (and most uses of the word "flux") refer to. Flux is an architecture pattern for applications where a lot of logic can run on the client. Its goal is to disconnect changes to state (the "model" in MVC terms) from the effect that should have on the view. This assumes that the view is a layer that can cheaply update itself without knowing what part of the state changes - a full "re-render" should be cheap and effective. React is a library that allows this. Once the view can update itself without knowing what state changed, one side of the disconnect between state and UI has been solved. The other side is how to manage state when user actions change it. When the model is a big blob of mutable data, this is easy: just update whatever you want to update, trigger a full re-render of the view and be done with it. But this has two disadvantages: first, it's often difficult to serialize this model and send it over the wire, which means prerendering on the server for snappy startup times is difficult. Second, people often prefer the model layer to be built of immutable data, because that makes React re-rendering faster. Flux tries to make working with serializable, immutable data easier by introducting what they call a "unidirectional data flow": user actions go into a "dispatcher", which in term knows which little sub-part of the model, called a Store, wants to turn that action into a data change. The stores, in turn, tell the view to re-render and that's it. The view can query the stores but not change the data in them: that's done only by sending actions through the dispatcher. The core insight of Flux is that dealing with immutable data is pretty easy if you split the model up into a limited number of simple "Stores", the granularity of which determines much of how well Flux works for you. If you manage to get them not too big and not too small, dealing with immutable data is not difficult anymore and React gets snappy updates. And serializing immutable data to JSON is pretty easy, because it's guaranteed to be a tree, so prerendering both the HTML and the initial dataset on the server is a done deal. Sorry, not 30 seconds. Does this help at all? Personal commentary: I'm not convinced that Flux is the final solution. Before Flux was popular, I led a React team with a model layer that was plain old mutable JavaScript objects, and it worked remarkably well. It was a big cyclic graph of objects that all referred to one another. Typical oldschool OO data model design. The big disadvantage was that re-rendering was slower, but IMHO we need to find a better solution around that. The guys who invented React said "what? all that spaghetti code just to keep model and HTML in sync? i just want to rerender every time just like we used to do with PHP on the server! i'm going to find a workaround" and invented the virtual DOM. In the same spirit, there has to be a way to make mutation of state simpler and still be fast and support universal ("isomorphic") apps. Mutable state is rather unpopular these days, but if there's one place where it shines, it's UI development.
  - andybak 11y ago
    Isn't the dislike of mutable state based on maintainability? i.e. more different things can poke at your state, the harder it is to reason about case and effect and the harder it is to prevent race conditions and a host of other problems. I'm feeling this in a back-end app and I'm wondering whether I can make use of some of these concepts to make things more manageable.
    - danabramov 11y ago
      Yes. You will enjoy this talk: http://blog.confluent.io/2015/03/04/turning-the-database-inside-out-with-apache-samza/ http://blog.confluent.io/2015/03/04/turning-the-database-ins...
- surganov 11y ago
  Great article on subject: http://blog.andrewray.me/flux-for-stupid-people/ http://blog.andrewray.me/flux-for-stupid-people/
gschrader 11y ago
The hardest part of learning React is trying to figure out which incarnation of flux one should use.
- skrebbel 11y ago
  If at all.
- Shizka 11y ago
  I agree. I am currently in the early stages of starting a project and I want to use react+flux. However with the different variants of flux finding the one that is the best fit and is going to be maintained a year from now isn't an easy task. I think I might end up using the facebook variant as I'm fairly certain that they will continue to maintain it.
- theaqua 11y ago
  I'm using alt.js[1] at now (very good implementation without boilerplate such switch/cases), but waiting Redux 1.0. [1] http://alt.js.org http://alt.js.org
- rattray 11y ago
  I really hope NuclearJS (by optimizely) wins out. It shares the "pure function" philosophy of Redux, along with use of Immutable.JS and a really powerful notion of functional data transforms/lenses called 'getters'. Docs are incomplete: http://optimizely.github.io/nuclear-js/ http://optimizely.github.io/nuclear-js/
  - danabramov 11y ago
    Redux doesn't care what you use for state, so you may (or may not) use ImmutableJS too. Here's an example of the “getters” concept with Redux: https://github.com/faassen/reselect https://github.com/faassen/reselect. (Sorry, no README yet :-( ). They don't have to be inside the core.
  - seivan 11y ago
    I actually like Reflux https://github.com/spoike/refluxjs https://github.com/spoike/refluxjs It's not "Pure" Flux, which is the reason I like it, it doesn't deal with a Dispatcher and it has syntactic sugar for 'common' use-cases, most Rails dev enjoy stuff like that. Seems like Reflux can't have hot-reloading because there is no (public?) dispatcher to replay values :-/
danabramov 11y ago
Hey, lib author here. Let me first explain Flux in five seconds. Instead of mutating your models, any data mutation in your app is described as a plain object describing “what happened” (e.g. { type: LIKED_POST, postId: 42 }) and broadcasted globally. Models (called Stores in Flux) have no setters and change their internal state in response to specific mutation objects (called Actions). The goal of Flux is to have single source of truth and make it easy to avoid race conditions and cascading updates. If some data is wrong, just repeat the same Actions in the same order, and you'll get the same data in Stores. Very easy to debug. Now, for Redux. It keeps the properties of Flux (mutations described as objects), but instead of Stores mutating internal state, it has Reducers—pure functions with (state, action) => state signature. While writing Flux apps, I noticed that the _essence_ of every Store I ever wrote was a reducer function. It turns out that using pure functions instead of event emitters has many benefits: they are composable (https://gist.github.com/gaearon/d77ca812015c0356654f https://gist.github.com/gaearon/d77ca812015c0356654f), it is possible to hot reload their logic (https://camo.githubusercontent.com/5688a6141e6a86baca5d252463dbbce86f8f71d2/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f662e636c2e6c792f6974656d732f325a324433553236306432413331316b3242307a2f53637265656e2532305265636f7264696e67253230323031352d30362d3033253230617425323030332e3232253230706d2e676966 https://camo.githubusercontent.com/5688a6141e6a86baca5d25246...). I wrote Redux for my React Europe talk about Hot Reloading and Time Travel (https://github.com/react-europe/cfp-2015/blob/master/live-react/proposal.yaml https://github.com/react-europe/cfp-2015/blob/master/live-re...). It got popular before I explained _why_ I made it. In my talk I show what kind of powerful devtools it is possible to build on top of Redux. The video of my talk will be up soon, you can check when it appears here: https://www.youtube.com/channel/UCorlLn2oZfgOJ-FUcF2eZ1A?app=desktop https://www.youtube.com/channel/UCorlLn2oZfgOJ-FUcF2eZ1A?app.... Also check out my article on the subject: https://medium.com/@dan_abramov/the-evolution-of-flux-frameworks-6c16ad26bb31 https://medium.com/@dan_abramov/the-evolution-of-flux-framew... EDIT: THE VIDEO IS UP! https://www.youtube.com/watch?v=xsSnOQynTHs https://www.youtube.com/watch?v=xsSnOQynTHs
- adeptima 11y ago
  Hi Dan, Great job. Hot reloading is SO HOT .. in your hands! Would you please share your plans for Redux, Redux DevTools and other tools you are working on? What's your vision for React based tools in such quick changing environment? I'm really scared to move all my projects to React base cause constant breaking changes. Coming packages splits in React 0.14, rush into ES6/7 rewrites, etc. is a huge hit for guys like me who can code only in free time outside of standard business hours. I would rather follow someone with strong vision ;))) ... and it seems you got your own. Please share what's on your mind. P.s. And yee ... please do presentation at MoscowJS ;)) http://www.moscowjs.ru/ http://www.moscowjs.ru/ https://www.facebook.com/groups/moscowjs/ https://www.facebook.com/groups/moscowjs/ Ilya S
vjeux 11y ago
Here's the video about it from React Europe: https://www.youtube.com/watch?v=xsSnOQynTHs https://www.youtube.com/watch?v=xsSnOQynTHs
- Rygu 11y ago
  And if you like Dan's talk, check out his blog post My Inspiration to get some more background on the topic. https://medium.com/@dan_abramov/my-inspiration-ce454ab65f33 https://medium.com/@dan_abramov/my-inspiration-ce454ab65f33 BTW vjeux, great job at React Europe!
- spicyj 11y ago
  One of my favorite talks I've seen. Highly recommended.
akst 11y ago
There needs to be more web tools with hot reloading support
asabil 11y ago
This is pretty much elm (http://elm-lang.org http://elm-lang.org) and elm architecture (https://github.com/evancz/elm-architecture-tutorial/ https://github.com/evancz/elm-architecture-tutorial/)
- danabramov 11y ago
  Yes, and you can find them in "Inspiration" section and the end of the README.
  - MikeOfAu 11y ago
    Where did the idea of (db action) => db come from? A reduction?
amelius 11y ago
Does it cope well with large amounts of data, and streaming of data? So far, all of the frameworks I have seen break down in such cases. And it is really a pain to pull a framework out of a project because it stopped meeting performance constraints.
- AriaMinaei 11y ago
  Could you give an example of where a certain framework would break under large amounts of data?
staltz 11y ago
Redux is a major improvement over Flux libraries because it removes a lot of boilerplate while not removing functionality (in fact, enabling more features). In Flux libraries, it's common for an entity to take inputs and simply produce outputs. That's not the use case for a class. It's the use case for a function, and that's why Redux removes boilerplate. However, I think it's time we stop calling everything Flux. Just because an architecture is unidirectional doesn't mean it's Flux. Facebook described it clearly as an architecture structured with: Dispatcher, Stores, Actions, Action Creators, and Components (sometimes even with the distinction of View and Controller View). Redux is Flux-inspired, but has significant differences. Maybe we should call it just Flux-inspired architecture. The distinction is important because there are other unidirectional data flow architectures such as in Elm (https://github.com/evancz/elm-architecture-tutorial https://github.com/evancz/elm-architecture-tutorial) and Cycle.js (http://cycle.js.org http://cycle.js.org). We might be creating confusion when mentioning "Flux" and meaning different things.
- Yomguithereal 11y ago
  I think you are right. It's time we give a proper name to these unidirectional data flow architectures and fly away from the Flux naming.
  - mycelium 11y ago
    Once terminology gets momentum it's hard to change it, it's usually not totally semantically meaningful (socket?!), but it's nice to have a convention. I think isomorphic JS is a ridiculous term, but at least there's a word for it. I've been using capitalization to denote the difference, just like Agile vs agile: Facebook's Flux or an implementation of the Flux architecture, versus a flux architecture.
    - staltz 11y ago
      By the way, with regard to isomorphic JS: https://medium.com/@mjackson/universal-javascript-4761051b7ae9 https://medium.com/@mjackson/universal-javascript-4761051b7a...
    - 11y ago
nickstefan12 11y ago
People should really just use the actual name for it: CQRS There would be a lot less future confusion over what's flux or not. It's actually a really old design pattern called command query responsibility separation. http://www.codeproject.com/Articles/555855/Introduction-to-CQRS http://www.codeproject.com/Articles/555855/Introduction-to-C...

186 points by monort 11y ago

To begin, I'm not quite sure what flux is. https://github.com/facebook/flux https://github.com/facebook/flux is this the flux it's for? It seems opaque to me at this stage. It reminds me of when Google released Polymer. There was a lot of generic stuff - but no elevator pitch. Explain to me in 30 seconds what's flux and where it sits?

skrebbel 11y ago
Flux is two things: a library by facebook (which you linked to), and a set of vaguely specified ideas. It's the second definition this article (and most uses of the word "flux") refer to. Flux is an architecture pattern for applications where a lot of logic can run on the client. Its goal is to disconnect changes to state (the "model" in MVC terms) from the effect that should have on the view. This assumes that the view is a layer that can cheaply update itself without knowing what part of the state changes - a full "re-render" should be cheap and effective. React is a library that allows this. Once the view can update itself without knowing what state changed, one side of the disconnect between state and UI has been solved. The other side is how to manage state when user actions change it. When the model is a big blob of mutable data, this is easy: just update whatever you want to update, trigger a full re-render of the view and be done with it. But this has two disadvantages: first, it's often difficult to serialize this model and send it over the wire, which means prerendering on the server for snappy startup times is difficult. Second, people often prefer the model layer to be built of immutable data, because that makes React re-rendering faster. Flux tries to make working with serializable, immutable data easier by introducting what they call a "unidirectional data flow": user actions go into a "dispatcher", which in term knows which little sub-part of the model, called a Store, wants to turn that action into a data change. The stores, in turn, tell the view to re-render and that's it. The view can query the stores but not change the data in them: that's done only by sending actions through the dispatcher. The core insight of Flux is that dealing with immutable data is pretty easy if you split the model up into a limited number of simple "Stores", the granularity of which determines much of how well Flux works for you. If you manage to get them not too big and not too small, dealing with immutable data is not difficult anymore and React gets snappy updates. And serializing immutable data to JSON is pretty easy, because it's guaranteed to be a tree, so prerendering both the HTML and the initial dataset on the server is a done deal. Sorry, not 30 seconds. Does this help at all? Personal commentary: I'm not convinced that Flux is the final solution. Before Flux was popular, I led a React team with a model layer that was plain old mutable JavaScript objects, and it worked remarkably well. It was a big cyclic graph of objects that all referred to one another. Typical oldschool OO data model design. The big disadvantage was that re-rendering was slower, but IMHO we need to find a better solution around that. The guys who invented React said "what? all that spaghetti code just to keep model and HTML in sync? i just want to rerender every time just like we used to do with PHP on the server! i'm going to find a workaround" and invented the virtual DOM. In the same spirit, there has to be a way to make mutation of state simpler and still be fast and support universal ("isomorphic") apps. Mutable state is rather unpopular these days, but if there's one place where it shines, it's UI development.
- andybak 11y ago
  Isn't the dislike of mutable state based on maintainability? i.e. more different things can poke at your state, the harder it is to reason about case and effect and the harder it is to prevent race conditions and a host of other problems. I'm feeling this in a back-end app and I'm wondering whether I can make use of some of these concepts to make things more manageable.
  - danabramov 11y ago
    Yes. You will enjoy this talk: http://blog.confluent.io/2015/03/04/turning-the-database-inside-out-with-apache-samza/ http://blog.confluent.io/2015/03/04/turning-the-database-ins...
surganov 11y ago
Great article on subject: http://blog.andrewray.me/flux-for-stupid-people/ http://blog.andrewray.me/flux-for-stupid-people/

gschrader 11y ago

The hardest part of learning React is trying to figure out which incarnation of flux one should use.

skrebbel 11y ago
If at all.
Shizka 11y ago
I agree. I am currently in the early stages of starting a project and I want to use react+flux. However with the different variants of flux finding the one that is the best fit and is going to be maintained a year from now isn't an easy task. I think I might end up using the facebook variant as I'm fairly certain that they will continue to maintain it.
theaqua 11y ago
I'm using alt.js[1] at now (very good implementation without boilerplate such switch/cases), but waiting Redux 1.0. [1] http://alt.js.org http://alt.js.org
rattray 11y ago
I really hope NuclearJS (by optimizely) wins out. It shares the "pure function" philosophy of Redux, along with use of Immutable.JS and a really powerful notion of functional data transforms/lenses called 'getters'. Docs are incomplete: http://optimizely.github.io/nuclear-js/ http://optimizely.github.io/nuclear-js/
- danabramov 11y ago
  Redux doesn't care what you use for state, so you may (or may not) use ImmutableJS too. Here's an example of the “getters” concept with Redux: https://github.com/faassen/reselect https://github.com/faassen/reselect. (Sorry, no README yet :-( ). They don't have to be inside the core.
- seivan 11y ago
  I actually like Reflux https://github.com/spoike/refluxjs https://github.com/spoike/refluxjs It's not "Pure" Flux, which is the reason I like it, it doesn't deal with a Dispatcher and it has syntactic sugar for 'common' use-cases, most Rails dev enjoy stuff like that. Seems like Reflux can't have hot-reloading because there is no (public?) dispatcher to replay values :-/

danabramov 11y ago

Hey, lib author here. Let me first explain Flux in five seconds. Instead of mutating your models, any data mutation in your app is described as a plain object describing “what happened” (e.g. { type: LIKED_POST, postId: 42 }) and broadcasted globally. Models (called Stores in Flux) have no setters and change their internal state in response to specific mutation objects (called Actions). The goal of Flux is to have single source of truth and make it easy to avoid race conditions and cascading updates. If some data is wrong, just repeat the same Actions in the same order, and you'll get the same data in Stores. Very easy to debug. Now, for Redux. It keeps the properties of Flux (mutations described as objects), but instead of Stores mutating internal state, it has Reducers—pure functions with (state, action) => state signature. While writing Flux apps, I noticed that the _essence_ of every Store I ever wrote was a reducer function. It turns out that using pure functions instead of event emitters has many benefits: they are composable (https://gist.github.com/gaearon/d77ca812015c0356654f https://gist.github.com/gaearon/d77ca812015c0356654f), it is possible to hot reload their logic (https://camo.githubusercontent.com/5688a6141e6a86baca5d252463dbbce86f8f71d2/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f662e636c2e6c792f6974656d732f325a324433553236306432413331316b3242307a2f53637265656e2532305265636f7264696e67253230323031352d30362d3033253230617425323030332e3232253230706d2e676966 https://camo.githubusercontent.com/5688a6141e6a86baca5d25246...). I wrote Redux for my React Europe talk about Hot Reloading and Time Travel (https://github.com/react-europe/cfp-2015/blob/master/live-react/proposal.yaml https://github.com/react-europe/cfp-2015/blob/master/live-re...). It got popular before I explained _why_ I made it. In my talk I show what kind of powerful devtools it is possible to build on top of Redux. The video of my talk will be up soon, you can check when it appears here: https://www.youtube.com/channel/UCorlLn2oZfgOJ-FUcF2eZ1A?app=desktop https://www.youtube.com/channel/UCorlLn2oZfgOJ-FUcF2eZ1A?app.... Also check out my article on the subject: https://medium.com/@dan_abramov/the-evolution-of-flux-frameworks-6c16ad26bb31 https://medium.com/@dan_abramov/the-evolution-of-flux-framew... EDIT: THE VIDEO IS UP! https://www.youtube.com/watch?v=xsSnOQynTHs https://www.youtube.com/watch?v=xsSnOQynTHs

adeptima 11y ago
Hi Dan, Great job. Hot reloading is SO HOT .. in your hands! Would you please share your plans for Redux, Redux DevTools and other tools you are working on? What's your vision for React based tools in such quick changing environment? I'm really scared to move all my projects to React base cause constant breaking changes. Coming packages splits in React 0.14, rush into ES6/7 rewrites, etc. is a huge hit for guys like me who can code only in free time outside of standard business hours. I would rather follow someone with strong vision ;))) ... and it seems you got your own. Please share what's on your mind. P.s. And yee ... please do presentation at MoscowJS ;)) http://www.moscowjs.ru/ http://www.moscowjs.ru/ https://www.facebook.com/groups/moscowjs/ https://www.facebook.com/groups/moscowjs/ Ilya S

vjeux 11y ago

Here's the video about it from React Europe: https://www.youtube.com/watch?v=xsSnOQynTHs https://www.youtube.com/watch?v=xsSnOQynTHs

Rygu 11y ago
And if you like Dan's talk, check out his blog post My Inspiration to get some more background on the topic. https://medium.com/@dan_abramov/my-inspiration-ce454ab65f33 https://medium.com/@dan_abramov/my-inspiration-ce454ab65f33 BTW vjeux, great job at React Europe!
spicyj 11y ago
One of my favorite talks I've seen. Highly recommended.

akst 11y ago

There needs to be more web tools with hot reloading support

asabil 11y ago

This is pretty much elm (http://elm-lang.org http://elm-lang.org) and elm architecture (https://github.com/evancz/elm-architecture-tutorial/ https://github.com/evancz/elm-architecture-tutorial/)

danabramov 11y ago
Yes, and you can find them in "Inspiration" section and the end of the README.
- MikeOfAu 11y ago
  Where did the idea of (db action) => db come from? A reduction?

amelius 11y ago

Does it cope well with large amounts of data, and streaming of data? So far, all of the frameworks I have seen break down in such cases. And it is really a pain to pull a framework out of a project because it stopped meeting performance constraints.

AriaMinaei 11y ago
Could you give an example of where a certain framework would break under large amounts of data?

staltz 11y ago

Redux is a major improvement over Flux libraries because it removes a lot of boilerplate while not removing functionality (in fact, enabling more features). In Flux libraries, it's common for an entity to take inputs and simply produce outputs. That's not the use case for a class. It's the use case for a function, and that's why Redux removes boilerplate. However, I think it's time we stop calling everything Flux. Just because an architecture is unidirectional doesn't mean it's Flux. Facebook described it clearly as an architecture structured with: Dispatcher, Stores, Actions, Action Creators, and Components (sometimes even with the distinction of View and Controller View). Redux is Flux-inspired, but has significant differences. Maybe we should call it just Flux-inspired architecture. The distinction is important because there are other unidirectional data flow architectures such as in Elm (https://github.com/evancz/elm-architecture-tutorial https://github.com/evancz/elm-architecture-tutorial) and Cycle.js (http://cycle.js.org http://cycle.js.org). We might be creating confusion when mentioning "Flux" and meaning different things.

Yomguithereal 11y ago
I think you are right. It's time we give a proper name to these unidirectional data flow architectures and fly away from the Flux naming.
- mycelium 11y ago
  Once terminology gets momentum it's hard to change it, it's usually not totally semantically meaningful (socket?!), but it's nice to have a convention. I think isomorphic JS is a ridiculous term, but at least there's a word for it. I've been using capitalization to denote the difference, just like Agile vs agile: Facebook's Flux or an implementation of the Flux architecture, versus a flux architecture.
  - staltz 11y ago
    By the way, with regard to isomorphic JS: https://medium.com/@mjackson/universal-javascript-4761051b7ae9 https://medium.com/@mjackson/universal-javascript-4761051b7a...
  - 11y ago

nickstefan12 11y ago

People should really just use the actual name for it: CQRS There would be a lot less future confusion over what's flux or not. It's actually a really old design pattern called command query responsibility separation. http://www.codeproject.com/Articles/555855/Introduction-to-CQRS http://www.codeproject.com/Articles/555855/Introduction-to-C...