

Ask HN: About the application architecture Flux - diggan

I recently got the word about Flux from a colleague of mine. It&#x27;s an application architecture Facebook uses for developing web applications. It&#x27;s all about single direction data flow where it&#x27;s easy to predict the changes that happens. To me, it sounds good but trying to find more information about it is not easy... Neither is there any bigger examples on the website.<p>So do anyone here on HN have any examples of similar architectures that have been used for a longer time, with some testimonials? Or maybe someone already have gone crazy and implemented it already and have some pointers of gotchas.<p>Some links:
From React documentation - https:&#x2F;&#x2F;facebook.github.io&#x2F;react&#x2F;docs&#x2F;flux-overview.html
Recent blogpost on React blog - https:&#x2F;&#x2F;facebook.github.io&#x2F;react&#x2F;blog&#x2F;2014&#x2F;05&#x2F;06&#x2F;flux.html
======
mattgreenrocks
It's not directly related to Flux, but it's worth thinking about.

Way before we outsourced every project's architecture to this week's framework
du jour (only to complain about it later), I worked on many projects with
somewhat ad-hoc architectures in an agile-like manner. We knew of MVC, but we
didn't necessary reach for it explicitly. Instead, we just tried to extract
domain/business logic out of the desktop UI layer as often as we could, and
called it good. Instead of constantly worrying about cramming everything into
small conceptual boxes, we just wrote code and decoupled what we thought might
change.

Flux reminds me of those times because it is far less prescriptive than MVC.
There's a certain freedom to just letting the code grow (assuming you prune it
as you go), rather than constantly worrying about whether this feature should
go in the model/presenter/controller/whatever.

A caveat: I'm almost certain part of the clarity comes from the delivery
mechanism being far more conceptually sound than HTML/CSS/JS.

------
lhorie
There were some comments on this related thread:
[https://news.ycombinator.com/item?id=7719957](https://news.ycombinator.com/item?id=7719957)

I wrote a micro framework called Mithril (
[http://lhorie.github.io/mithril](http://lhorie.github.io/mithril) ) that has
a similar single-direction-data-flow architecture. Here's a small snippet to
illustrate how the flow of data works there:

    
    
      //model
      function getFoo() {
        return m.request({url: "/visits", method: "GET"})
      }
      function setFoo() {
        return m.request({url: "/visits", method: "POST"})
      }
    
      //controller
      function controller() {
        this.foo = getFoo()
        
        this.save = function() {
          this.foo = setFoo()
        }.bind(this)
      }
    
      //view
      function view(ctrl) {
        return m("div", {onclick: ctrl.save}, [
          "hello " + ctrl.foo()
        ])
      }
    
      m.module(document, {controller: controller, view: view})
    

Basically data goes from `getFoo` in the model to `this.foo`, which is used as
`ctrl.foo()` in the view. Firing the `onclick` event on the view triggers a
`save` _action_ in the controller, which calls `setFoo` in the model. `setFoo`
sends data to `this.foo` which is again used as `ctrl.foo()` in the view, and
on goes the M -> V -> C -> M ... cycle. Within the context of the template,
the unidirectional flow is seen by the fact that the data just gets consumed
as we recursively go down the template tree, without reading stuff back from
the template as we go. This is in stark contrast to jQuery, where we typically
call a series of methods to read and update arbitrary parts of the DOM in a
non-atomic, state-machine kind of way.

Flux uses different nomenclature (e.g. they use the term _stores_ for model-
like entities, and the _dispatcher_ is analogous to controller actions that
translate a UI event into a command to update data) and some of the
implementation details as they relate to React are a little bit different from
Mithril (e.g. React has the concept of a _controller-view_ , which is a sort
of "root subscriber" in view land, _props_ to pass data down the component
tree, etc), but the idea is that application state can be thought of as a
monolithic blob of data that mutates atomically as it gets corecursively
passed through an MVC-like system, rather than a state machine that gets
incrementally tweaked by a bunch of ad-hoc commands.

