

McFly – Flux Architecture Made Easy - danso
https://github.com/kenwheeler/mcfly

======
bengotow
I wish someone would create a large Flux/Reflux demo app. I love the "one-way
data flow" model and the patterns established by Flux/Reflux, but I feel like
I would really benefit from seeing a large, complex application where stores
depend on stores (or keep state independently?) etc. The example ToDo apps
everyone publishes are too trivial to really gain an understanding of how to
apply the patterns.

~~~
andrewvc
We were in a similar spot. Our startup is building a relatively large flux
app. We interviewed Ian Obermiller of FB on a lot of the concerns of a large
app. You can find a lot of answers to tough questions in our transcript:
[http://ianobermiller.com/blog/2014/09/15/react-and-flux-
inte...](http://ianobermiller.com/blog/2014/09/15/react-and-flux-interview/)

~~~
cnp
Awesome, thank you so much for this.

------
rymohr
How is this different from reflux?
[https://github.com/spoike/refluxjs](https://github.com/spoike/refluxjs)

~~~
thekenwheeler
So McFly is basically pure Facebook Flux. I even use their Dispatcher. What
I'm doing is creating a helper factory to DRY-up some of the Stores and
Actions boilerplate code, because in the examples they are freeform and not
instances of any object. So the answer to the question is essentially:

[https://github.com/spoike/refluxjs#differences-with-
flux](https://github.com/spoike/refluxjs#differences-with-flux)

~~~
rymohr
Did you use reflux before writing McFly?

I like reflux but I'm worried it may be leading me astray from the core
principles that make the flux architecture so useful. It's one of those things
you can't be sure of until the app grows complex enough to start running into
edge cases (such as waitFor and the single dispatcher, separation of actions
from action creators, keeping async code out of stores, etc).

~~~
thekenwheeler
I did, and it's really cool, but I felt the same way. So I wanted to bridge
the gap.

------
megaman821
Question about the Flux pattern in general, why is a dispatcher/store more
desirable than an observable model? The biggest difference I see is a
component can add or delete an object with no knowledge of a store just the
global dispatcher, but why not just have a static method on a traditional
model for adding and deleting?

~~~
thekenwheeler
I think the biggest difference is that Stores don't necessarily contain just
one object. They are state containers, so where with a Model you would have
singular object based static methods, in a Store you could have methods to
manipulate or return any of the objects it contains.

~~~
megaman821
Fair enough, but why coordinate Store actions through a Dispatcher? Is there
much to gain over just calling a method on the Store?

~~~
lfischer
For me, the gain is that you can track all interactions in a single spot. If
stores trigger updates on each other, you end up with a web of dependencies
that take a long time to trace through when making changes or debugging.

------
vuldin
I'm liking how there are new projects popping up who all implement the flux
pattern, but do so in different ways. I haven't looked into how this differs
from something like fluxxor, but the example looks simple and easy to use. My
one grip with the jsfiddle is a nitpicky one: that the McFly object is being
given the Flux name... that could be confusing for people who are looking at
this and also using the flux library from facebook (which has a different
API).

~~~
thekenwheeler
Sorry about that. I was kind of at a loss for what to call the new instance.

~~~
vuldin
How about mcfly? :D

~~~
thekenwheeler
Hah. In my own projects I've been cameling it like var mcFly = new McFly()

------
skorecky
I still don't understand why developers want this over something more
simplistic like this:
[http://jsfiddle.net/quje39qa/1/](http://jsfiddle.net/quje39qa/1/) \- Am I
alone in thiking JS frameworks are not the future?

~~~
armandososa
The to-do app is just an example, an over-simplistic one, but if you ever try
to write any large-ish app using the jQuery approach you'll get your answer.

~~~
colinramsay
I agree with you, but to be fair it is possible to build a large jQuery-only
application and be successful. You'd just end up re-inventing a lot of things
that a framework could have given you, or writing a lot more code. You'd also
have to impose strict guidelines for your developers, since there'd be no
"established" way of doing certain things (the first time round).

~~~
mateuszf
That's why React is brilliant, since it's really simple and scales well.

~~~
colinramsay
In association with Flux I assume you mean?

~~~
moystard
React can be used without a Flux-like architecture. It can also be integrated
in a MV* application, see Backbone React Component[1] for example that uses
Backbone Model for rendering React components.

[1] [https://github.com/magalhas/backbone-react-
component](https://github.com/magalhas/backbone-react-component)

~~~
watty
Couldn't we say any view layer "scales well" when integrated other
architectures?

~~~
Smudge
No. Some view layers require you to specify a lot more of the state transition
code and may be more heavily integrated with the rest of your architecture
(like the way you do data binding, etc). Because React transparently updates
state by simply re-rendering components, you can keep it very cleanly
decoupled from the rest of your architecture. There are other frameworks that
accomplish similar tasks, but I've found that none come quite so close to
having zero lines of state transition code as React. (In React, most of my
state transition code involves visual animations.)

------
bkurtz13
No project like this ever amounted to anything in the history of The Valley!

~~~
cnp
Its not the project, but the ease in which it enables you to understand _the
concept_

