
Introduction to Facebook's Flux architecture - wayfarer2s
http://ryanclark.me/getting-started-with-flux/
======
susi22
Has anybody in the client side community ever made the connection to rules
engines?

This flow of logic is awfully close to how a rule engine works. I wonder if
people will at some point arrive at it.

There isn't a whole lot of rules engine in JS. Just nools [1] which is huge.
I'd love to see a very simple forward chaining rule engine + Immutable + React
and see how that would work out.

My guess is that they aren't popular at all because they have the notion of
being enterprisey (Drools/Jboss). I'm a big fan of them. They /can/ make life
& code very nice and elegant. Maybe somebody writes an JS adapter to clara
rules [2].

[1] [https://github.com/C2FO/nools](https://github.com/C2FO/nools)

[2] [https://github.com/rbrush/clara-rules](https://github.com/rbrush/clara-
rules)

~~~
tel
I would like to see a series of examples in the use of rules engines. I've
worked in several places where people brought them up as suggestions, but
their "enterprisey" brand made them harder sells.

------
megaman821
Everytime I see the Flux architecture I wonder what does it bring to the table
that a reactive programming library like RxJS or Bacon.js don't? It seems Flux
is just hacking together well-defined concepts in these libraries.

* Stores could use Observables instead of EventEmitter

* Components become Observers by subscribing to Observables which is extremely similar to setting up Listeners.

* Instead of Actions through a Dispatcher, Actions become Proxies (or Subjects in RxJS terms or Buses in Bacon.js terms) that Stores subscribe to and Components push to.

~~~
jlongster
The dispatcher really is just a simple pub/sub mechanism.

The thing that Flux helps define is how to manage data. We don't have models,
but it gives you a coarse structure for your data, with which you can do stuff
like data dependencies (derived data), only rerendering part of your UI when
parts of your data changes, etc.

How events are used within all of this could certainly be re-purposed with Rx
(I've repurposed it as channels myself). You are not wrong, but flux is a bit
more formalized with a few more things.

~~~
megaman821
That makes sense. Just all the code samples I have seen of Flux have most the
lines of code dedicated to wiring up events instead of the more interesting
things you have mentioned. I think just using either Rx or CSP would make the
concepts of Flux clearer.

~~~
jlongster
I bet if you dug around the internet there are some good examples of that.
I've been meaning to show more examples with js-csp, but Rx is pretty popular
so I bet there's some examples with that.

I bet many of the Flux implementations use a simple event system because
that's the lowest common denominator; we're all pretty used to wrapping that
in whatever we like anyway. But it does make a little more confusing to look
through.

------
sepeth
Is there a way to get rid of flux boilerplate? I don't want to write three
different files (a file with actions, another file with constants, and the
actual store). For example, I can achieve the same effect with just a simple
array and some functions to modify it. I guess I know what the benefit of
embracing flux is, but it still looks too much, and I am mostly lazy.

~~~
veeti
Reflux is a Flux library without the dispatcher boilerplate.

~~~
cnp
+1 On Reflux. They have an awesome new async api now, too.

------
j_s
_themgt_ posted the following on the currently trending React thread, sharing
what appears to be Flux's impending sunset:

 _One of the things I didn 't realize at first was the degree to which
Relay/GraphQL appear to effectively replace a lot of Flux:
[http://facebook.github.io/react/blog/2015/02/20/introducing-...](http://facebook.github.io/react/blog/2015/02/20/introducing-
relay-and-graphql.html)

Learning Flux sort of seems like learning how to drive stick shift on an '97
Civic while we wait for the new Tesla to arrive - useful, also a bit annoying.
A central store architecture does seem a better match to what Relay will look
like though._

[https://news.ycombinator.com/item?id=9094255](https://news.ycombinator.com/item?id=9094255)

edit: fixed link; thanks!

~~~
mrec
Looks like that first link got truncated to the ellipsized display form when
you copypasted; full one should be;

[http://facebook.github.io/react/blog/2015/02/20/introducing-...](http://facebook.github.io/react/blog/2015/02/20/introducing-
relay-and-graphql.html)

------
balls187
> If you're like me and you wanted to go further with React, you more than
> likely would've checked out Flux, had a glance, closed the tab and then
> reassessed your life as a * developer.

This accurately describes my experience yesterday.

I think React is quite expressive in it's simplicity. Flux on the other hand
(even though it's good idea), is poorly tooled out.

~~~
breatheoften
Flummox
([https://github.com/acdlite/flummox](https://github.com/acdlite/flummox))
looks quite interesting to me as a more 'tooled out' flux implementation

------
Bahamut
Heh, this post resonates with me - Facebook's description of Flux drew a wtf
when I first looked at the diagrams on
[https://facebook.github.io/flux/docs/overview.html#content](https://facebook.github.io/flux/docs/overview.html#content)
with its weird terminology, but when I did some more further research into it,
I found out that I had a lot of very similar patterns with my Angular code.

I think they should have chose some better terminology/words to describe the
overall components, in this case I found the words shutting down my thought
process on first glance.

~~~
jared314
> had a lot of very similar patterns with my Angular code

I had the same "weird terminology" and "thought stopping" reaction to
Angular's, Ember's, and Meteor's architectural terminology. I know they're all
trying to differentiate themselves in a crowded market, but its just created
more of a mess.

Time for me to go learn a new dictionary, to do the same job I did yesterday.

------
jedireza
I actually think it's a good to understand Flux in it's purest sense before
using a framework. As a learning experiment I created Aqua
[[https://github.com/jedireza/aqua](https://github.com/jedireza/aqua)]. It was
published last week and there's a good Q&A thread going on
[[https://github.com/jedireza/aqua/issues/2](https://github.com/jedireza/aqua/issues/2)].

------
wnevets
I must be missing something, I see a lot of boilerplate code for minor gain.

------
goldendase
I find the idea of Flux fascinating, but one thing I'm a little curious about
is where error feedback fits in here... If an AJAX query fails, or something
fails validation, how does this information make its way back to the view? If
it happens at the action dispatch level, you still have to pass the event
through the store? That seems a little... Odd to me.

~~~
jbhatab
You can make your ajax calls in actions or stores so if it makes sense to.
Just make the query there to easily update the store.

~~~
goldendase
Right, my question isn't where the call should be made though. Makes perfect
sense in the actions. My question is if the call fails how do I post a
notification to the view itself to communicate to the user that something went
wrong? Actions can't post back to Views, so... Send event to store, store
passes along the error to view? It's an elegant system otherwise, but this
really clumsy to me.

~~~
bigonlogn
Stores hold the state your Views use to render. This can include more than
just the data backing the Views. It can include things like which item is
selected in a list, if a link is active or not, and any error messages as
well.

------
raziel2p
Some of the code examples given here are perfect examples of what I hate about
javascript.

assign(new Dispatcher(), {methodName: function() {}})

Why can't I just define a regular class? Even worse, in the following code
snippet the arguments seem mismatched with the previous one:

assign({}, EventEmitter.prototype, {methodName: function() {}})

I can accept this sort of thing if the payoff is high, like getting access to
the performance and simplicity of virtual DOM operations in React, but these
examples just seem to be to create basic objects.

Maybe object-assign is one of the javascript best practices that keep changing
every 2 months and I'm just not paying attention enough? ES6 can't come soon
enough.

~~~
nemothekid
I think assign should be replaced by having a native class in ES6. I've
thought of it like

assign(some newly allocated object, base class [, base class...], object with
methods).

It seems to get around the funny stuff with new, prototypes and references.

~~~
raziel2p
Feels like yesterday I was told Object.create was the new best way to do this.

~~~
jsnoble
The class in ES6 is just syntactic sugar over Object.create. Class is only
coming out becuase most people wont learn that javascript has prototypal
inheritance, and how to use it. Its a different mental model, in my opinion
prototypal inheritance is more expressive and light weight than typical
classes from other languages

------
cssmoo
Perhaps a huge coincidence but I pretty much wrote this framework in C# in
2004 (including rules engine) and was using it for mobile devices
(wince/symbian). We abandoned it after 4 years for a simple CQRS system with
event bus (before Udi/Greg went off on it or Fowler formalised it).

You know where we are now? Simple JSON REST API with local and remote queues
per device updating a document store. All the queues have on receipt and on
dispatch handlers attached and that is it. Each of these can modify the state
or perform an external action.

YMMV but I'd probably start there first. It's much easier than the other two.
I might write it up.

------
andreamazz
It's always nice to read a writeup on Flux. I would love to hear more about
possible isomorphic implementation of the architecture though. Right now
besides Fluxible the architecture doesn't play well with server side
rendering. By the way, shameless plug, I wrote an article on Flux (backed by a
Rails API) a while ago, if you're interested on the matter:
[http://fancypixel.github.io/blog/2015/01/28/react-plus-
flux-...](http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-backed-
by-rails-api/)

~~~
fizzbatter
What specifically do you mean when you say that it doesn't play nice with
serverside?

I wrote my own Flux implementation (back when it was first announced, and
there were no/limited libraries for it), and i don't recall having a problem
with my implementations.

I probably broke a few rules though, hard to say. I'd be curious to hear your
experiences with it :)

~~~
Bockit
I can't speak for the OP, only my experience here. The docs on flux[1]
recommend singletons for the dispatcher and stores. If your library is
following that recommendation then things start breaking in a server-side
environment as multiple requests start hitting, especially in parallel with
asynchronous data retrieval.

[1]: [https://facebook.github.io/flux/](https://facebook.github.io/flux/)

~~~
andreamazz
Exactly, I was referring to the singleton stores and dispatcher

------
giovannibonetti
I've run gulp and then got this error, related to CSS/SASS:

Message: error /Users/gkbonetti/code/flux-getting-
started/public/src/scss/partials/_messageBox.scss (Line 3: Invalid CSS after "
&": expected "{", was "__list {"

"__list" may only be used at the beginning of a compound selector.)

~~~
skinofstars
Guessing you're on ruby 1.9.3 or something. Update to ruby 2.x first
(brightbox ppa is good for this on Ubuntu types), then gem install sass.

------
dismal2
Love going through live examples to learn, thanks for sharing!

But, I can get it to render (after doing npm/bower install then running gulp),
but can't get it to actually do anything. Everything looks right but clicking
around and nothing happens? Anyone else running into this?

~~~
sehr
Make sure you're on the latest branch, step-five

~~~
dismal2
thanks! missed that,

------
Aleman360
So... a global message bus? That will quickly become spaghetti in a large code
base.

~~~
illicium
Hey, it has a cool name and it's made by Facebook. It must be state of the art
tech, right?

Trolling aside, Flux really doesn't bring much to the table. It's trying to
solve the pain caused by two-way-binding by forcing state to flow in one
direction through an event bus, reinventing MVwhatever along the way.

You can already do this stuff in Angular (et al) if you stick to a few firm
rules for how to structure your app.

~~~
istorical
Don't blame you if you don't have time nor motivation to respond, but care to
share a 2 min. description of those rules?

I'm a fairly new developer working in my first post-uni role and we're
starting to rack up a lot of Angular code and I'm not sure if I'm structuring
things right as far as events vs $watches etc.

~~~
illicium
A few off the top of my head:

* Use ui-router. Build your app with nested views.

* Any duplicate page elements should be directives. Use isolated scope when you can and pass state into directives explicitly

* Keep model state in services. Controllers handle binding data to $scope (one way, from model to view) and handling events from the view

------
nileshtrivedi
The author of Reflux argues against having a single dispatcher though:
[http://spoike.ghost.io/deconstructing-reactjss-
flux/](http://spoike.ghost.io/deconstructing-reactjss-flux/)

------
ph0rque
Is there an example using e.g. the rails asset pipeline / ruby gems instead of
bower?

------
andyl
Flux newbies should check out the Reflux implementation.

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

One of the best features is that Reflux lets you chain stores to eliminate
WaitFor.

~~~
jbhatab
Also check out
[https://github.com/goatslacker/alt](https://github.com/goatslacker/alt).

It's similar to reflux but in es6.

------
harisamin
interesting

------
juancastro
This is awesome!

------
juancastro
Testing LibHN 4.0.1? LOL me as well

------
mlangenberg
Don't people realize that returning HTML instead of JSON will solve their
problem for 80% of the use cases?

Looking at Relay/GraphQL, the whole picture appears as a gigantic layer of
indirection to generate a DOM tree, something you could do serverside 10
layers below.

Even 'Components' are just fragments of HTML, retrieving them in the format
you want from the server is much easier. And be honest, replacing a fragment
of HTML in the DOM is fast enough for most applications. (don't delete form
input, though)

How does all of this bring Web Development forward? Look at this blog post for
example: [http://fancypixel.github.io/blog/2015/01/28/react-plus-
flux-...](http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-backed-
by-rails-api/)

In 2006, after part 1 you would be done and call it a day. Now I understand
that today you need 'realtime' updating. But the "notification count is off by
one" Facebook example is really bad, because instead of doing all the math in
JS, one can simply do a GET request to fetch the count from the actual Single
Point Of Truth, which is your database.

Did this get so complicated because front-end development and back-end
development is separated at many places?

~~~
meistro
Agree that the trend to assemble HTML client side has complicated development
way more than it should have. However, returning html fragments isn't the
solution for all use cases. Consider native apps for Android/iOS/OSX/Windows.
They will need data to be delivered via an API. Instead of creating a one-off
data pipeline for web browsers, consuming data from a standard API cuts out
the need to assemble views for a specific platform. Creating applications via
the browser just isn't up to par with the ease of creating applications in
other environments (mobile, pc).

~~~
babuskov
You can have both.

The way I did this in some of my apps is that JSON data is shared between web
and Android/iOS client, BUT rendering that data into HTML is done server side:

The server detects if the request is coming from the browser or client app. If
it's the client app. it just hands over the JSON data. If it's the browser, it
uses the same data to render HTML and sends that to the browser.

