
Marty.js – A JavaScript library for state management in React applications - jfhollingworth
http://martyjs.org/
======
hakanderyal
Nice documentation, and dev tools is a big plus.

The beauty of flux + react is, it's so simple and flexible.

I'm developing a fairly complex application with flux + react, (no flux
frameworks, just facebook's dispatcher and stores/actions modelled after
facebook's flux examples), and it seems I've implemented lots of things in
marty.js. I also started using mixins for subscribing views to stores,
immutable data in stores (so undo/redo is available without much work),
loading data into stores from different sources etc.

I believe, in the following months, a de-facto flux framework will emerge, and
marty looks so close to being that framework.

A few tips to fellow developers want to try react and/or flux:

\- React is just the view part. Integrating it with other frameworks is easy,
and integrating other js libs with react is also easy.

\- OTOH, if you want to build a whole complex app with react, use something
like flux with it, since there isn't a flexible way to modify the app state
from child components with react.

\- Immutable data structures really goes well with react + flux. I haven't
been able to get the immutability/functional style before, and react + flux
really helped with that.

Thanks again for the great tools.

~~~
eric_bullington
Great comment and excellent intro to React for interested devs. I've been
successfully using React for small and mid-sized apps, and agree that Marty
looks like it's an elegant solution to the Flux pattern. (for application
state in React, I've also had some success with passing around an immutable
cursor, like react-cursor[1]).

One cautionary note about how easy it is to integrate React with other
frameworks: this statement is true as long as the framework in question
doesn't touch the DOM (e.g., using Backbone models). But if you try to
integrate React with any JS library or framework that mutates the DOM, you
should be aware that this will interfere with React's DOM "accounting" and
potentially cause lots of problems.

There are certainly ways around this (look into the lesser-used React life
cycles), but it's much easier to stick within the React ecosystem for any
libraries that manipulate the DOM, or build your DOM manipulations from
scratch (easy to do with React). Already, there's a fairly feature complete
React Bootstrap library [2]. I've started work on a React charting library,
using d3 for path calculations and other utilities (and temporarily for chart
axes generation, but library users shouldn't have to worry about any DOM
issues) [3]. And I'm sure there are a thousand and one other React view-level
component libraries I'm not familiar with, most of which are likely available
via NPM.

But I agree that React and the other virtual DOM libraries and frameworks
(Ractive, Mercury, Om, etc.) are the next generation approach for client-side
views. They not only make DOM manipulations much snappier, but they also make
them much easier for the developer.

1\. [https://github.com/dustingetz/react-
cursor](https://github.com/dustingetz/react-cursor)

2\. [https://github.com/react-bootstrap/react-
bootstrap](https://github.com/react-bootstrap/react-bootstrap)

3\.
[https://github.com/esbullington/react-d3](https://github.com/esbullington/react-d3)

~~~
Confiks
> (for application state in React, I've also had some success with passing
> around an immutable cursor, like react-cursor[1]).

The react-cursor library really introduced cursors based on immutable data for
me. I've never used the library, but the idea stuck. Omniscient looks very
shiny as well, but it too invasively changes the workings of React for me.

Immutable.js provides a great Immutability library, with a very lightweight
cursor implementation on top. You can make a simple object that recursively
updates itself with the newest state from the cursor. You have to merge
updated states at the keyPath to prevent clobbering from 'synchronous' updates
at different cursors.

If you give that object a listen(), a getCurrentState() and a private
trigger() method, you are well on your way to a complete store. Reflux offers
roughly this model, and adds much needed actions and listening to other
stores.

Here's a gist with a tightly coupled (incomplete) example store that emits a
cursor, and a React component that listens to the store and updates it:

[https://gist.github.com/confiks/745d27f7308db1935eb9](https://gist.github.com/confiks/745d27f7308db1935eb9)

~~~
albertoleal
By the way, the hypothetical reflux store in your gist is basically this:
[https://github.com/omniscientjs/immstruct](https://github.com/omniscientjs/immstruct)

Thus, you can simplify to something like this:
[https://gist.github.com/Dashed/707664be1319bb222c7c](https://gist.github.com/Dashed/707664be1319bb222c7c)

\-------

Omniscient is still useful in that you can make your own `component` shim
using their `shouldComponentUpdate()`.

I think the reflux model doesn't too synergize well with immutable-js's
cursors. I found out that reflux with omniscient/immstruct ended up being one
more level of indirection. Plus, I didn't need all the features that reflux
provided. I even tried a super-light version of reflux.

So I replaced reflux with an augmentation upon immstruct with more useful
features (a library I've yet to release). I'm still experimenting with it
while investigating a nice isomorphic architecture.

------
colinramsay
I'm scanning the documentation for this now and the "state sources" concept
looks useful. Stores seem to be a bit cleverer than in other Flux
implementations too.

The fact it's got a Chrome extension and what appears to be comprehensive
documentation bodes well. I'm currently using reflux because I like its
simplicity (no dispatcher and no action creators) but Marty has definitely
piqued my interest.

Edit: Question for the author. Any thoughts on isomorphic apps with Marty?
Edit2: Answering my own question:
[https://github.com/jhollingworth/marty/issues/13](https://github.com/jhollingworth/marty/issues/13)

~~~
jfhollingworth
Isomorphic apps are the next big challenge. Right now the biggest blocker is
that everything's a singleton. I'm working on an internal container which
should hopefully mean existing apps can be made isomoprhic without a change to
the API

~~~
btown
I've found that contexts are a good way to handle this - they're basically
invisible props that get implicitly passed down the component tree, and mixins
can whitelist which parts of the context they want to be able to use. They're
undocumented, but they're used quite widely in React, so I doubt they're going
anywhere. You can have a top-level component instantiate new dispatchers and
stores and expose them as i.e. "this.context.userStore",
"this.context.dispatcher" to mixins and component code. And this can be done
concurrently in the same Node process without needing VMs/sandboxing. Your
state mixin API might need to change a bit, but it can be substantially the
same:

var UserState = Marty.createStateMixin({ listenTo: "UserStore", getState:
function (UserStore) { return { users: UserStore.getAll() }; } });

A reference: [https://www.tildedave.com/2014/11/15/introduction-to-
context...](https://www.tildedave.com/2014/11/15/introduction-to-contexts-in-
react-js.html)

Fluxxor, FYI, bundles all of this in context.flux:
[https://github.com/BinaryMuse/fluxxor/blob/master/lib/flux_m...](https://github.com/BinaryMuse/fluxxor/blob/master/lib/flux_mixin.js)

------
daveidol
One thing I would love to see some guidance on with Flux (and potentially with
the patterns expressed in Marty.js) is how to handle the use case of Stores
for a collection of items as well as a single item.

Right now, if I create a Store for a collection of Users and I want to be able
to mutate these User objects then I create actions for each CRUD mutation and
then plumb that change through to the in-memory object inside my collection as
well as persist the change to my server.

But as soon as I click on a specific User and load up a new page for that
User, for example, then I need to create an all new Store just for a single
User, which has all of the same mutations/actions available to it as the
previously-mentioned collection Store (except now I don't need to pass the ID
to every action payload).

The best approach I've seen on this topic is in this example's Readme:
[https://github.com/gaearon/flux-react-router-
example](https://github.com/gaearon/flux-react-router-example)

Does this approach make sense/jive with the Marty.js way of handling Stores,
State Sources, etc?

~~~
hakanderyal
The method that you linked is the one I use currently.

Another way is to use a nested immutable data structure (something like
immutable.js[1], react-cursor[2]), use only one store, and make all changes on
this data structure and pass accordingly.

Even if you don't use immutable.js, I strongly suggest to use immutability
with react update[3] or equivalent. Things get way easier that way.

[1]: [https://github.com/facebook/immutable-
js](https://github.com/facebook/immutable-js)

[2]: [https://github.com/dustingetz/react-
cursor](https://github.com/dustingetz/react-cursor)

[3]:
[https://facebook.github.io/react/docs/update.html](https://facebook.github.io/react/docs/update.html)

~~~
daveidol
Thanks for the suggestions. I've looked at immutable data structure libs some,
but I haven't seen any real comprehensive examples showing the behavior you
describe within the Flux pattern. Do you happen to know of any such examples?

I ask because the examples I see for react-cursor, etc typically show data
being mutated directly inside the React component without using
Actions/Stores/etc. Going this route means we lose the advantages such as a
unidirectional data flow & the ability to centralize logic for interacting
with a Store around well-defined Actions.

So if we did merge the Flux idea with Cursors, I assume we would keep a single
Cursor as the underlying state inside a Store, and then use the traditional
Action/ActionCreator model to allow React components/server updates to mutate
this Store?

What is the big win here then vs. traditional (non-immutable) Stores (other
than performance gains by using === in shouldComponentUpdate)? It seems to me
you would still have to make a separate Store for editing a single item vs
editing a collection.

------
peterjmag
Out of curiosity, for those of you building stuff with Flux: Which library do
you use? Or do you just use your own implementation?

We recently went with Reflux[1] for our first big React app after reading
about it here[2], and I've been pretty happy with it so far.

[1] [https://github.com/spoike/refluxjs](https://github.com/spoike/refluxjs)

[2] [https://reactjsnews.com/the-state-of-flux/](https://reactjsnews.com/the-
state-of-flux/)

~~~
bsimpson
I'm using Reflux for now, though I'm tempted to switch to something more FRP
like Bacon, f, or RxJS. I find that I end up making stores for both AllThings
and CurrentThing, and it should be easier to express that relationship with
FRP.

~~~
kylemathews
I've been using a "FilteredConnect" mixin that I wrote that's solved the
"CurrentThing" store problem nicely.

~~~
bsimpson
Interesting. Link?

~~~
kylemathews
Still private — need to create a pull request against Reflux.

------
rattray
This looks great. The docs really are terrific, too.

Personally, I've been playing around with Bacon.js (or RxJS) instead of the
Flux dispatcher. Using `Bacon.update` in conjunction with Facebook's
Immutable.js seems really promising. The outcome is a far more functional
approach.

A quick and dirty example:
[https://gist.github.com/rattrayalex/dee40d86813bcaa9de80](https://gist.github.com/rattrayalex/dee40d86813bcaa9de80)

~~~
computmaxer
Have you considered omniscient with Immutable.js?
[https://www.npmjs.com/package/omniscient](https://www.npmjs.com/package/omniscient)

~~~
rattray
It was the inspiration for my current setup, actually!

Ultimately, pure-Bacon seems more functional, and I wanted to use something
where all the "primitives" (Immutable, Bacon, etc) can be used directly, and
are extremely well-supported. I may add a few abstractions (eg; a basic Mixin
for event-binding, along the lines of [0]), but would prefer not to have a
framework that "does too much" or has much magic, at least until it's very
widely-used.

[0]
[https://www.npmjs.com/package/fluxbone](https://www.npmjs.com/package/fluxbone)

------
rpwverheij
I'm using react quite a lot, but with my own API / storage solutions. So far
I'm not really familiar with flux, and also with this, just quickly looking at
it, I don't understand if/why I would need it. I can't really wrap my head
around what exactly all this allows me to do and can't bring up the effort to
read all the docs. I think I'll read more about flux first at some point, and
if I'll ever want to use that, come back and check Marty :) Happy to see
active react development though

~~~
jasim
In your typical React component, you'll keep state in the parent, and pass
them down as props to the children's subtrees. You also have to pass down
handlers (`handleNameChange` for example) along with the props so that the
child components can change the state. These handlers travel back to the
parent, modify the state there, which triggers a re-render, and that travels
from the parent down all the way to all the children again. This works for
most use cases.

This however forces you to keep all your model logic (computation,
transformation, validation and server-communication) in the parent view
component. So you'll extract a Model out of it, in which you keep all this
data and logic. All the handler methods in the parent component would then
call the mutation methods in this model instead of changing the component
state directly. But now you need to ensure that the component state is
consistent with the model state, for which you hook into the Model's onChange
callback in the component's `componentDidMount` method. This means whenever
the Model mutates, the component state changes accordingly. For example, if
you have a `setPageTitle` method in the Store (that's what we call our Models
in Flux), the store would mutate the value when `setPageTitle` is invoked, and
call its own `emitChange` method, which triggers the `onChange` callback on
the component which was registered during its `componentDidMount`.

See:
[https://github.com/facebook/flux/blob/master/examples/flux-c...](https://github.com/facebook/flux/blob/master/examples/flux-
chat/js/components/ThreadSection.react.js#L34). You use EventEmitter (I prefer
EventEmitter3) on the Store to make it an observable. See:
[https://github.com/facebook/flux/blob/master/examples/flux-c...](https://github.com/facebook/flux/blob/master/examples/flux-
chat/js/stores/ThreadStore.js#L56).

The first step in Flux is this: a simple View-Model separation using an
EventEmitter store. Apart from the View-Model separation, this lets you share
global state between multiple components. (Global state is bad for
programmers, but the real world doesn't care. There are instances where you
need to share the same data between multiple components and have them all
update automatically)

In the ThreadStore example I linked to above, the `emitChange` method is
called only through the Dispatcher at the bottom. This is the next step: we do
not let any component modify the store values directly. Everything is
channeled through a uni-directional dispatcher. The reason to do this is to
avoid one Store talking to another Store talking to another, and each of these
causing cascading state changes in the components that observe them. So
instead of having multiple intertwined paths to the Store, you force the
entire application to go through a single-channel dispatcher that process each
Action in sequence.

The Actions are simply constants that are available globally to invoke
specific behaviour across one or many stores. Each Store watches out for the
Actions (a constant pushed into its mesage bus) they are interested in, and
calls the appropriate method in its body. You push the Actions into the
dispatcher, who is responsible for sending it to each Store.

The dispatcher uses the same EventEmitter observable pattern to bind each
Store to the actions they are interested in.

Written in a hurry, but I hope it helps. The flux-chat repo
([https://github.com/facebook/flux/blob/master/examples/flux-c...](https://github.com/facebook/flux/blob/master/examples/flux-
chat)) is a great place to understand the entire pattern.

~~~
rpwverheij
this is really helpful. I was looking for a short from-typical-react-to-flux-
example compact enough to read through at once. I get it much better now, and
actually I have already a framework with models with 'global' state and use
react to visualise them and have been wondering what would be the best way to
do this (copy the models data into state, or try to skip state and use the
model data directly). So I guess I'll have to have a better look soon. Thank
you for pulling me over the line

------
lrichardson
This looks to be a well-put-together implementation of flux. I recently looked
over around 20 or so flux libraries to use for a react app I had started, and
found only a couple that I liked. I would put this one near the top, but the
one I ended up choosing has been _great_ , but no one seems to know about it!

If anyone is interested:
[https://github.com/kjda/ReactFlux](https://github.com/kjda/ReactFlux)

It's very similar, but I think I like how Actions and subscriptions to actions
are handled with it better.

~~~
UberMouse
I also decided to use ReactFlux after looking around at the flux
implementations. It kind of suffers from the fact no one knows about it but it
feels a lot better to use than the other implementations I looked at. I forked
the library to support nested objects in the store state and I'm pretty happy
with it now.

But I may switch to Marty since I'm not far along with the project and the dev
tools look super helpful.

~~~
lrichardson
Funny... I actually created some store mixins to do the exact same thing.

I've done it slightly different than you... rather than using `mergeDeep` in
`this.setState`, I created some other methods such as
`this.setStateAtPath(path, value)` and `this.mergeState` (the latter would use
`mergeDeep`)

I'm going to submit a PR to allow for store mixins to be a little more 1st-
class:
[https://github.com/kjda/ReactFlux/issues/4](https://github.com/kjda/ReactFlux/issues/4)

------
agilebyte
In Marty: since you attach a Store to a React via a Mixin that looks for a
singleton, can you have a dynamic number of stores when you have a dynamic
number of React components of the same type?

~~~
dalacv
This sounds like a line from a movie for a character which is the nerd/genius
in the movie.

I'm not very technical, by the way.

~~~
elwell
Would make sense given Marty is a reference to Marty McFly from _Back to the
Future_ ; having to do with state management through time and, of course,
_Flux_ capacitors.

~~~
bronson
And it wouldn't be the first time:
[https://github.com/kenwheeler/mcfly](https://github.com/kenwheeler/mcfly)

------
oliverwoodings
I've contributed to this project on the state sources.

For me Marty is the best Flux implementation available right now. When
reviewing other frameworks I found them to be either too restrictive by
imposing non-flux limitations or the complete opposite by not implementing the
flux principles well enough.

------
bryanlarsen
I've been using fynx[1], and it seems to work for me so far.

What attracted me to fynx was that it uses Facebook's immutable-js[2] for its
stores.

It would be nice to get an updated version of this comparison of available
flux libraries[3].

1: [http://foss-haas.github.io/fynx/](http://foss-haas.github.io/fynx/) 2:
[https://github.com/facebook/immutable-
js](https://github.com/facebook/immutable-js) 3: [https://reactjsnews.com/the-
state-of-flux/](https://reactjsnews.com/the-state-of-flux/)

------
STRML
This seems very similar to Fluxxor, but solves some of the pain points.

Stores need to be extendable, and the Mixin concept (as used in React
Elements) are a very useful way to do it. In this way, one can easily
implement Marty's "State Sources" concept. I released a fork of Fluxxor a
while ago with Mixin support [1] but it is unlikely to make it until 2.0.

The other nice parts to my eyes are:

State Mixins - sort of a hybrid between Fluxxor's StoreWatchMixin and Fluxxor-
autobind [2]

Constants - This is a new one, I like it. Will have to play with it to see if
it truly solves any problems; I've found that when I need to know what actions
are available, I scan my actions files, simple as that.

Marty seems a little more "batteries included" than the other Flux
implementations on the scene. This is a good thing, so long as it is easy to
extend. Unfortunately I still don't see Mixins in Marty Stores either. In my
opinion they are required for non-trivial apps.

1\.
[https://github.com/STRML/fluxxor/tree/storeMixins](https://github.com/STRML/fluxxor/tree/storeMixins)

2\. [https://github.com/STRML/fluxxor-
autobind](https://github.com/STRML/fluxxor-autobind)

~~~
jfhollingworth
Author here: Marty stores do have mixins, think I forgot to add them to the
docs

~~~
STRML
Great! That's a big plus for me.

------
picardo
Nice documentation. But I don't see anything groundbreaking here. The whole
rationale for Flux is to unidirectional state flow, and it does that quite
well. A lot of library creators have focused on the tiny quibbles with "ease
of use" around stores and constants –– "state management" is a good euphemism
for this need –– but that's not really a bottleneck for me. I can manage my
constants manually with Flux, and add listeners myself. If I need to indicate
a dependency between to stores, I can use a waitFor in the switch/case block.
It's that simple. Why should I learn a bunch of abstractions that make only an
incremental difference?

My only pet peeve with Flux is that it does not let me dispatch from within an
ongoing dispatch, which is not a huge deal yet because you can just defer the
callback to the next event loop, but it's not allowing me to pipeline actions
as I thought it should. I have to wait for the stack to empty out before I can
dispatch a new action, which sucks. Also, there is no indication as to when a
dispatch is over, so I am deferring dispatches by instinct –– or wrapping them
in a promise might be the same thing.

~~~
jfhollingworth
Hey, author here. This is a repeat of my answer below but it's right down the
bottom so might be missed:

I found that no other Flux implementation really helped with fetching data in
a Fluxy way. There tended to be a lot of boiler plate code for binding stores
to components. Furthermore, there was a lack of tooling for debugging. Marty
helps combat these issues by introducing a number of new things:

\- Fetch API for fetching data asynchronously without callbacks
[http://martyjs.org/guides/stores/fetching-
data.html](http://martyjs.org/guides/stores/fetching-data.html) \- State
Mixins for binding stores to views [http://martyjs.org/api/state-
mixin/](http://martyjs.org/api/state-mixin/) \- State sources for syncing
state from heterogeneous sources [http://martyjs.org/guides/state-
sources/index.html](http://martyjs.org/guides/state-sources/index.html) \-
Chrome Developer extension (beta) for visualising the data flow and state of
stores [http://martyjs.org/devtools/](http://martyjs.org/devtools/)

~~~
picardo
You're right about the boilerplate. I use a wrapper around React.createClass
to take care of that. Kinda similar to Marty.createStateMixin, but it's just a
component factory.

The Chrome plugin looks very nice, but you can do the same thing with
console.log() outputs in your store. It's a nice to have, but not filling a
need for me.

~~~
catshirt
> The Chrome plugin looks very nice, but you can do the same thing with
> console.log() outputs in your store.

by that logic, you don't need a debugger with breakpoints and stack traces
either.

i mean... you could use a spoon for driving nails into wood instead of a
hammer, too.

~~~
picardo
I could also use a jackhammer, but that's not what jackhammers are for.

------
thomasfl
Even if HN readers are getting tired of all the new "Javascript librairie de
jour", it's really exciting to see how new techniques are refined and improved
in a fast tempo. Keep them libraries coming!

------
joesb
I really want to use React in my next application, but I'm lost on how to do
visual things like animation (like a carousel), drag-drop, typeahead.

Do you have any suggestion on the best practice on doing those heavy DOM stuff
in React?

I know I can use jQuery for that, but it feels wrong to me.

Also how do you handle integrating React with command based JS library, where
your only interface to it is to call mutating functions, such that you cannot
blindly rerender the whole things.

Suggestions on these two issues would help me greatly.

------
riffraff
In
[http://martyjs.org/guides/flux/index.html](http://martyjs.org/guides/flux/index.html)
it says

> thanks to action types being strings you have a loosely coupled Law of
> Demeter architecture which is easy to grow without increasing the complexity
> of the code base.

I don't see the connection between cause and effect, unless this is saying
"since everything is in the global state there is no coupling". Seems odd.

------
jordanlev
This looks really neat, and the documentation does seem nice. What I would
absolutely _love_ (and I'm sure many others as well) is a tutorial that shows
how to build a very simple app from scratch... like a list of records and then
click on a record to bring up an edit form (something super basic, but a tad
more complex than TodoMVC). The problem I have is wrapping my head around how
I put all the pieces together. Thanks!

------
joesb
I hope all the virtual-DOM based library comes to concensus with one based
virtual-DOM library, or that it becomes part of the browser standard.

I don't mean the whole React library, I mean just "this a the DOM before,
here's the change, now patch it" part.

More and more framework and UI library are going to be built around vritual-
DOM concept. I don't want integration nightmare of UI-libraries working only
on some React-like library.

------
chadscira
Does marty.js support the concept of an app context? The only implementation i
know of is Yahoo's fluxible
([https://github.com/yahoo/fluxible](https://github.com/yahoo/fluxible)). This
is mainly useful when you're trying to render your flux app on the server.

~~~
jfhollingworth
Not right now but isomorphisim is the next big feature I'm going to be working
on

~~~
chadscira
Awesome, i have been in search for a good solution for isomorphic flux
implementations.

------
corford
Slightly OT but has anyone tried Marionette + React as a combo? Would be very
interested to hear how smoothly (or not) it went.

------
prottmann
Can't see a difference between marty and fluxxor.

The examples look for me the same, except some additional functions to declare
things.

~~~
jfhollingworth
Author here. I found that no other Flux implementation really helped with
fetching data in a Fluxy way. There tended to be a lot of boiler plate code
for binding stores to components. Furthermore, there was a lack of tooling for
debugging. Marty helps combat these issues by introducing a number of new
things:

\- Fetch API for fetching data asynchronously without callbacks
[http://martyjs.org/guides/stores/fetching-
data.html](http://martyjs.org/guides/stores/fetching-data.html) \- State
Mixins for binding stores to views [http://martyjs.org/api/state-
mixin/](http://martyjs.org/api/state-mixin/) \- State sources for syncing
state from heterogeneous sources [http://martyjs.org/guides/state-
sources/index.html](http://martyjs.org/guides/state-sources/index.html) \-
Chrome Developer extension (beta) for visualising the data flow and state of
stores [http://martyjs.org/devtools/](http://martyjs.org/devtools/)

~~~
bsimpson
Like many others, I've been using Reflux because it seems to be the easiest to
understand and to work with by reducing the surface area of concepts you need
to understand to just:

1) actions

2) stores.

In Reflux, a store is effectively just a variable you want your component(s)
to be able to access and an action is a function that tells the store what to
change about its state. For instance, I might have a CurrentUser store that
tracks who the current user is and notifies my Profile component when that
changes. I might also have a switchUser action that tells CurrentUser to
change its state to user #30. That's all you need to understand to use Reflux.

It's certainly interesting to have data fetching baked into Marty, but it also
introduces so many concepts. I think it'd be really helpful for people coming
from other libraries if you had a big glossary that says what each thing is
and why you felt a need to include it. What's a Marty constant and why is it
different than an action creator? What purpose does the dispatcher serve? etc.

You'd have a better time recruiting and training new users with a diagram that
shows how all these concepts fit together and why you need so many of them.

~~~
jfhollingworth
That's what I tried to do with this page
[http://martyjs.org/guides/flux/index.html](http://martyjs.org/guides/flux/index.html).
Let me know how I could improve it

~~~
bsimpson
I see a Get Started Now button on the home page (I didn't see it the first
time through). I'd add a How It Works button right next to it that links to
that Flux page. It's definitely helpful, although the constants and
dispatchers feel like implementation details that most developers shouldn't
have to think about.

You switch between "actions" and "action creators" in this paragraph, which
makes it hard to follow:

> Action Creators are where any changes to your applications state starts.
> Actions are functions that are responsible for coordinating changes to local
> and remote state. Actions have a type which is a string describing the
> action (e.g. "UPDATE_USER_EMAIL").

I thought the Action Creator was a function and the Action was the act of
invoking it, but that's not clear in the quoted section.

\-----

I think your documentation is a bit hard to follow because you're using
JavaScript in unexpected ways. For instance, it's a bit weird that your
constants are invokable:

    
    
        updateUserEmail: UserConstants.UPDATE_USER_EMAIL(function (userId, email) {
    

and I think the line after it mixed constants and action creators:

> In the above scenario, UserConstants.UPDATE_USER_EMAIL creates an action
> creator which, when invoked, will create an action with type
> UPDATE_USER_EMAIL.

\-----

You're missing a ( here:

    
    
        UserActionCreators.updateUserEmailthis.props.userId, email);
    

\-----

In the next example, you use the method name as a key and the constant that
triggers it as a value:

    
    
        handlers: {
          updateEmail: UserConstants.UPDATE_USER_EMAIL
        },
    

Since the convention in all the libraries I've seen is to use type as the key
and the callback as the value, most developers are going to be immediately
tripped up by this unless you call it out in the documentation.

\-----

Marty has some interesting ideas. Thanks for sharing them, and for taking the
time to make a website explaining them.

------
goatslacker
Congrats, the site looks really nice and the devtools feature is great!

------
dengar007
This looks fantastic. Great work on the documentation too!

------
knivets
Make for building — interesting.

------
kuni-toko-tachi
I like ReactJS, but I think Flux is overhyped. One-way dataflow is much better
handled via RxJS or BaconJS and as with Om thru cursors. Writing stores and
dispatchers and actions is a poor substitute for FRP.

~~~
lumpypua
_shrug_ They address different problems. Reactive systems are great but they
aren't an overall architectural approach. You have to come up with that
yourself.

Flux is an architecture.

I used BaconJS and I found that my overall page event and data flow ended up
being reactive spaghetti. Architecture is not my strong suit. One of the great
things about flux is having extremely strong conventions about where
everything goes:

\- All interactions are through actions.

\- All state is in stores.

\- No mutable state in the actual UI.

\- etc.

What's your overall dataflow architecture look like using RxJS or BaconJS?

~~~
mjohn
There is nothing stopping you using a flux-like architecture with RxJS or
BaconJS. For example, instead of action creators you can push to a Bacon.Bus
that is listened to by your store, which can be a Bacon.Property.

I found using BaconJS much nicer if I needed to transform data from
asynchronous requests because you end up with a much more functional approach.

