Redux: Atomic Flux with Hot Reloading

by monort • 11 years ago

186 44 11 years ago

anon3_• 11 years ago

To begin, I'm not quite sure what flux is.

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?

skrebbel2• 11 years 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• 11 years 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.

surganov• 11 years ago

Great article on subject: http://blog.andrewray.me/flux-for-stupid-people/

gschrader• 11 years ago

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

skrebbel2• 11 years ago

If at all.

Shizka• 11 years 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• 11 years 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

rattray• 11 years 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/

danabramov5• 11 years 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. (Sorry, no README yet :-( ). They don't have to be inside the core.

seivan• 11 years ago

I actually like Reflux 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 :-/

glenjamin• 11 years ago

The dirty secret is: they're probably all fine.

It's unlikely that you will choose a flux lib that will be the make or break point of your application.

Even if a library stops being "maintained", most decent flux incarnations are really small (~100 LoC) - it's unlikely that there's some fatal flaw you'll be stuck with.

In summary: redux is neat, but don't beat yourself up over choosing the perfect flux lib - just grab one that you like the look of and move on with building your application.

grandalf• 11 years ago

this is a great point. Also, since the overall architecture is going to be similar no matter which one you use, it's likely not going to be a major hassle to switch to a different one later.

lukasm2• 11 years ago

They all boil down to the same thing. I use this one https://github.com/acdlite/flummox minimum boilerplate

patio11• 11 years ago

Further boilerplate reduction: https://gist.github.com/patio11/b472ccb2df3e1fcce78c I was going crazy with all the sit-ups to hook actions/stores together prior to this.

applecore• 11 years ago

It's good practice to write your own Flux implementation for any new React project. It's pretty straightforward; just a few hundred lines of JavaScript.

danabramov5• 11 years 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), it is possible to hot reload their logic (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-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....

Also check out my article on the subject: https://medium.com/@dan_abramov/the-evolution-of-flux-framew...

EDIT: THE VIDEO IS UP! https://www.youtube.com/watch?v=xsSnOQynTHs

adeptima• 11 years 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/ https://www.facebook.com/groups/moscowjs/ Ilya S

tel• 11 years ago

They're a bit more than just reducers. Given that you always package them with initial state they're a little more like "left folds" [0] or "Moore machines" [1] (they're isomorphic). What's neat about this is that noticing that structure describes a whole bunch of ways to compose machines and folds—in particular, there's parallel composition like Flux suggests ("all stores receive the same actions", your linked example, https://gist.github.com/gaearon/d77ca812015c0356654f) and sequential ("category-like") composition.

[0] https://hackage.haskell.org/package/foldl-1.1.0/docs/Control...

[1] https://hackage.haskell.org/package/machines-0.5.1/docs/Data...

nemanja• 11 years ago

Hey Dan,

Redux looks awesome. I am using react-dnd and hot reloader on my current project and they are great. Thank you for all the great contributions you are making to the ecosystem.

The idea of modeling the store as a reducer is clever. Complication I see is that my action creators are often not pure functions (i.e. there is generally a side effect to update the database and persist the change). However, given the focus of redux on improving the dev workflow, I suppose database updates/side effects could be mocked out. How would you handle this scenario?

What would actually be awesome to have and go hand-in-hand with redux is an immutable write-only isomorphic database (for application state persistence), where you use the same initial state/reducer for redux and the database. Database stores initial state, logs actions and computes the current state using the reducer (and caches it) - much like redux on the client. Curious to hear what people think about this or if anyone has seen anything like it.

danabramov5• 11 years ago

Complication I see is that my action creators are often not pure functions (i.e. there is generally a side effect to update the database and persist the change).

https://github.com/gaearon/redux#how-do-i-do-async

Zagitta• 11 years ago

Thank you! I've been reading about Flux for a while now but your simple explanation just made it click

vjeux• 11 years ago

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

Rygu• 11 years 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

BTW vjeux, great job at React Europe!

spicyj• 11 years ago

One of my favorite talks I've seen. Highly recommended.

akst• 11 years ago

There needs to be more web tools with hot reloading support

asabil• 11 years ago

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

danabramov5• 11 years ago

Yes, and you can find them in "Inspiration" section and the end of the README.

MikeOfAu2• 11 years ago

Where did the idea of (db action) => db come from? A reduction?

amelius• 11 years 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• 11 years ago

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

staltz3• 11 years 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) and Cycle.js (http://cycle.js.org). We might be creating confusion when mentioning "Flux" and meaning different things.

Yomguithereal• 11 years 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• 11 years 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.

MikeOfAu2• 11 years ago

Also such as: https://github.com/Day8/re-frame

nickstefan12• 11 years 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-C...

Redux: Atomic Flux with Hot Reloading

Related Stories