

Redux: Atomic Flux with Hot Reloading - monort
https://github.com/gaearon/redux

======
staltz
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
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
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.

~~~
throwaway2210
Why is the term isomorphic so 'ridiculous'?

I've read Michael Jackson's article and I didn't interpret it as saying that
people using the term isomorphic are outright wrong. Some people are making
this assertion and that is what I am trying to refute here.

I disagree with Michael's statement that two things that are the same cannot
be isomorphic. The very definition he cites does not exclude the possibly of
those things being the same!

    
    
       "Corresponding or in similar form or relations"
    

(Even in mathematics the identity function is an isomorphism, it follows from
its definition. However, we are not trying to prove a mathematical property
here.)

But even then the assertion that the server and client side are exactly
identical is not correct. Typically such code bases will have slightly
different entry points for server and client. Additionally, React 0.14 beta is
now splitting the DOM and String renders.

For some 'Universal' is attractive, because they want to use Javascript
everywhere. I get that. If you like that, please go ahead and call it
'Universal'.

However, what matters equally is having an _abstraction_ which allows pure
functions to declaratively describe the form of components based on immutable
data, no matter what the computational model of the target. It is arguably the
abstraction that is the isomorphism and code that uses it could be called
isomorphic. That could be stretching the term as per the above definition, but
that doesn't mean that people who use it are wrong.

I think React provides the necessary abstraction. I have total respect for
what the React core team and the community have achieved. I understand that
Michael Jackson and Ryan Florence are motivated by wanting to get more people
using React. This is a very good thing.

However, other people may be more interested in promoting the ideas behind
React rather than React or Javascript specifically. It is these people I am
trying to defend.

~~~
MrManatee
The term "isomorphic JavaScript" also sounds strange to my ears. I think it’s
because in traditional use (in mathematics, linguistics, biology, etc.) you
don't say "X is isomorphic", you say that "X and Y are isomorphic".

Grammatically, it’s kind of like the word "similar". I would feel silly saying
"JavaScript is a similar language", and I feel equally silly saying
"JavaScript is an isomorphic language". Similar/isomorphic to what?

------
vjeux
Here's the video about it from React Europe:
[https://www.youtube.com/watch?v=xsSnOQynTHs](https://www.youtube.com/watch?v=xsSnOQynTHs)

~~~
Rygu
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!

------
asabil
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
Yes, and you can find them in "Inspiration" section and the end of the README.

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

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

~~~
rattray
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/)

~~~
seivan
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 :-/

~~~
Lazare
I wouldn't really recommend Reflux. What advantages it has are shared by
other, better libraries like alt or redux, but it has some disadvantages all
its own.

Ran across a good writeup here:
[https://www.reddit.com/r/javascript/comments/3ap0y6/flux_no_...](https://www.reddit.com/r/javascript/comments/3ap0y6/flux_no_more_stores_meet_reducer/csfpdo6)

~~~
andy_ppp
I am really enjoying Reflux personally and I think that's one of the good
things about React and the Fluxes; there's many mental models to suit
different ways of thinking about how to build apps.

There is no 100% correct way to build complex single page web apps but there
is definitely a wrong way and that way looks increasing like progressive
enhancement sadly...

------
danabramov
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/5688a6141e6a86baca5d25246...](https://camo.githubusercontent.com/5688a6141e6a86baca5d252463dbbce86f8f71d2/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f662e636c2e6c792f6974656d732f325a324433553236306432413331316b3242307a2f53637265656e2532305265636f7264696e67253230323031352d30362d3033253230617425323030332e3232253230706d2e676966)).

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...](https://github.com/react-europe/cfp-2015/blob/master/live-
react/proposal.yaml)). 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...](https://www.youtube.com/channel/UCorlLn2oZfgOJ-
FUcF2eZ1A?app=desktop).

Also check out my article on the subject:
[https://medium.com/@dan_abramov/the-evolution-of-flux-
framew...](https://medium.com/@dan_abramov/the-evolution-of-flux-
frameworks-6c16ad26bb31)

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

~~~
nemanja
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.

~~~
danabramov
>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](https://github.com/gaearon/redux#how-do-i-do-async)

------
nickstefan12
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...](http://www.codeproject.com/Articles/555855/Introduction-to-CQRS)

------
amelius
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
Could you give an example of where a certain framework would break under large
amounts of data?

------
anon3_
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
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
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
Yes. You will enjoy this talk: [http://blog.confluent.io/2015/03/04/turning-
the-database-ins...](http://blog.confluent.io/2015/03/04/turning-the-database-
inside-out-with-apache-samza/)

------
akst
There needs to be more web tools with hot reloading support

