
The Evolution of Flux Frameworks - tilt
https://medium.com/@dan_abramov/the-evolution-of-flux-frameworks-6c16ad26bb31#
======
goatslacker
Alt author here. I've actually begun to integrate some of the microflux ideas
into Alt itself. Alt already has a lot of the benefits mentioned in the post:
time travel, revert, record and replay debugging; but stores as reducers and
having them not own state makes for clean code. However, I don't think one
size fits all here, some stores are good as reducers of state and others fit a
larger role. There are actually many different types of stores that get
created in an application. This is really powerful but also confusing for
beginners coming from MVC.

Anyway I'm excited for what the future holds for flux and excited for relay.

~~~
girvo
_> There are actually many different types of stores that get created in an
application. This is really powerful but also confusing for beginners coming
from MVC._

Agreed wholeheartedly. One thing that MVC did was answer questions that
developers had about architecture, at a "this is how you should do it" level.
Now, granted, it answered them with a tonne of tradeoffs and didn't really
answer them well at all, in my opinion, but that's something that I've seen a
lot of Flux beginners somewhat struggle with. What you're doing with Alt is
helping bridge that gap, though.

My offer still stands regarding helping out with some slightly more
comprehensive example documentation/tutorials, by the way :) And thanks for
you help in #Reactiflux!

~~~
goatslacker
I'll take you up on that offer. Having comprehensive examples, documentation,
and tutorials is something that sets Alt apart and I'd definitely like to have
more of it.

You, and anyone else, is free to also contribute to alt itself, check out the
issues tagged with "help wanted"
[https://github.com/goatslacker/alt/issues?q=is%3Aopen+is%3Ai...](https://github.com/goatslacker/alt/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)

Patches are super welcome :)

~~~
girvo
Just commented on GitHub, looking forward to it!

------
codesuki
I really like Flux because the one directional flow makes it really simple to
reason about the code. But when I saw the dispatcher and all those switch case
statements that's where they lost me.

So I built this minimal flux library on top of RxJS and until now it did
everything I needed.

Maybe it's useful for someone else too.

[https://github.com/codesuki/reactive-
flux](https://github.com/codesuki/reactive-flux)

------
aaron-lebo
Where do you start with React/Flux?

I keep wanting to dip my toes in and I get the gist of why you'd use React
(less so Flux), but there's so many frameworks to choose from that I get
nervous about picking the wrong horse and find myself waiting until the dust
settles.

~~~
ravicious
You don't really need a framework, one can get pretty far without it. Look up
Facebook's Flux examples[1] to see how they're doing it.

[1]
[https://github.com/facebook/flux/tree/master/examples](https://github.com/facebook/flux/tree/master/examples)

~~~
nhunzaker
I tend to agree. Even as an author of one of the Fluxes (Fluxii?) mentioned, I
still think this is the best approach. All of implementations I've seen simply
formalize patterns the author was repeating on multiple projects.

(There's also know obligation to use them, the joy of OSS!)

------
weeksie
I'm surprised Reflux wasn't mentioned. I really don't see the need for a
dispatcher, but perhaps I am missing something important.

~~~
jbergens
We are currently using Reflux and it is very easy to get started with but it
uses singletons which was one of the things mentioned that they want to be
able to avoid. I still think Reflux is a great framework to start with but if
you want serverside rendering and other advanced stuff you should probably
check out the newer frameworks.

~~~
weeksie
Now that makes sense. Thanks!

------
pspeter3
I feel like the problem with Flux is the fact that there are multiple stores
that the developer has to deal with. It seems easier to combine them and use a
single "store" that has similar properties to Meteor, Firebase, PouchDb, etc..

~~~
baddox
Is there really a significant difference between having two stores called
UserStore and MessageStore, and having a single Store with state like {users:
userState, messages: messageState}?

~~~
jblock
I think it really depends on your implementation. For readability, having a
`UserStore` and `MessageStore` in one place might get to be troublesome,
especially when it comes to separating out business logic. But that said,
things like `Om` like to push the idea of a single application state object,
so I can forsee an implementation where you have multiple `Store`s that sit
atop a single `ApplicationStore`, such that you deal with the keys of `users`
and `messages` separately while they are attached to the same parent
`ApplicationState` object (which can be immutable and persistent as well).

------
modarts
I'll toss my vote in for Flummox; it's the only implementation I've seen that
nails Flux at the perfect level of abstraction and even interacts well with
es7 language features like async/await to make reasoning about async processes
easier

------
zefei
Compared to facebook's barebone flux library, the only real advantage these
frameworks provide is about server side rendering. But I'm worried this will
become irrelevant once facebook Relay is out.

~~~
rickharrison
To be fair, facebook only publishes the dispatcher. You are on your own to
figure out your stores, action creators, hooking it up to components, etc.

