Reflux.js Manifesto

Finding the idiomattic approach to using Reflux.js.

Please, treat these as heuristics, because:

  1. I do not necessarily know what I'm talking about.
  2. Idioms are not always the best way to break down a problem.

Got feedback?





New Data

New data can:

Even without new data, if the view wants state to change (eg SomeThing.toggleSelected), do so through actions.

Public API

Your business domain get's a clear public API comprised of:

I'm not sure about reading state from the stores. It might be possible to avoid using it in views, and keep the interface very narrow indeed.

Shared Modelling

From An Issue where Spoike discusses typical store->component updates and shared behaviour.

trigger passes the arguments over to the listeners... and I personally prefer to pass all the data that the components need through the event. I have passed the store itself (for quick prototype hacks) and use setters and getters. Both approaches are equal valid implementations and I don't want to enforce one over the other.

However I don't personally encourage the latter approach (of setters and getters on the store) since that usually has been a slipper slope to create stores that are "god classes". "God class" or "big ball of mud" are anti-patterns that I like to avoid.

As to how to reuse, I use mixins when applicable. If you think about them as traits, it makes it easy to attach functionality that you may want to reuse. If you need to add common methods to all stores you may add them to the Reflux.StoreMixin which is used during creation of stores.


It seems that the practice is to bring all your inital state and/or service state into stores, and then map reduce through stores to end up with calculated data representations your views can consume easily.

Regarding the kind of data in stores

Spoike suggests:

As far as Flux goes is it okay to store the global var map = Object instance inside a store as a plain JS variable and then have a getter/setter action to get that map instance across multiple components in my app, including Maps component itself?

Sure, if that works for you then it is okay. Stores are supposed to hold all the data that the components need between each other.

I'm of the opinion that you would try to avoid storing a whole map component (google map object), and have a controller view share it's state with the business model through busines-centric actions. This way you find yourself modelling your domain, not Googles.

Stores triggering actions

This one seems like it could become hard to reason about.

My concern is that this would introduce an action that:

I want to use these, they seem valuable.

There is a discussion here

Don't model in actions

Actions are the cause, stores are the effect.