The Evolution of Flux Frameworks | Hacker News Reader

The Evolution of Flux Frameworks

medium.com

70 pointstilt22 comments

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.

> 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!

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...

Patches are super welcome :)

Just commented on GitHub, looking forward to it!

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

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.

Absolutely. At first I was excited that there was so much activity. Simultaneously, it intimidates many engineers I talk to because of how much fragmentation there is.

Thankfully, the footprint of each framework is relatively small. I'd try to pick the one that seems to be the least encroaching (e.g. not using tons of custom components, something fairly agnostic about underlying data structure/data fetching methods). That way, if the tide suddenly changes, you're not buried up to your toes in messy, dying code.

You can also get by with React on its own! We've got a few areas in some of our Backbone apps where we've just decided to use raw XHR requests to fetch data (and nothing wrapping around the objects themselves).

So the TLDR is that I don't have a good panacea of a Flux library to recommend, but that shouldn't stop you from investigating React as a view mechanism in your applications.

Try to use React without anything just to get a feel for it and then you will find out by yourself what it needed to make it work and what are its good and bad points. Working with big frameworks is too opaque and you are restricted to do what they deem good.

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

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!)

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

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.

Now that makes sense. Thanks!

From what I understand(still a newbie) , Dispatcher helps organized store dependencies , the waitFor()

Reflux has that with the `.joinXX` functions. Perhaps there's something else there? I guess I can see some organizing factor but doesn't the dispatcher get really large in a complex application?

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..

This is the approach that many ClojureScript frameworks take, and I find it to be a much more elegant approach than Flux proper.

You use a single, immutable data structure to store your application state, and components use functional lenses to look into the part of the state they're dependent on and listen for changes.

In doing so, you get a free application history stack and deltas (for undo/redo, offline/online sync and some powerful debugging capabilities), extremely efficient shouldComponentUpdate implementations for all components, and opportunities for many more advanced optimizations like batching updates for rendering on requestAnimationFrame.

Check out Om if you'd like to take a look at the original ClojureScript implementation, or Morearty.js if you're interested in a pure JS alternative.

https://github.com/moreartyjs/moreartyjs

https://github.com/omcljs/om

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}?

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).

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

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.

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.

Reply on news.ycombinator.com