Hacker News Reader

Comment by jefftchan | Hacker News Reader

It's great to see Facebook releasing code for Flux. Hope to see more in the future. Here are some other implementations of Flux for anyone who's interested: https://github.com/BinaryMuse/fluxxor https://github.com/jmreidy/fluxy https://github.com/yahoo/flux-example

We recently adopted this architecture for a medium-scale project. The unidirectional data flow has greatly reduced code complexity for us. We're still not satisfied with our server syncing strategy. Seems like actions are the best place to sync data, but how do you deal with interdependent actions?

View on HN

I'm the author of Fluxy and would be happy to answer any questions here. The big benefits of Fluxy vs other Flux approaches is that 1) Stores are built on top of immutable data structures (via ClojureScript / mori) 2) Server side rendering is baked in (or will be as of 0.4)

I'd also mention https://github.com/spoike/reflux as an implementation.

I've been reading about ClojureScript/OM and mori. What example apps are online using either of them? This is what I've found so far.

ClojureScrpt/OM:

https://github.com/swannodette/om (several examples linked)

http://rigsomelight.com/2014/05/01/interactive-programming-f... (flappy bird clone)

React+Mori:

???

Fluxy has an example of using React + Mori - although it's still a work in progress as Fluxy is developed.

https://github.com/jmreidy/fluxy/tree/master/examples/todomv...

http://connecttous.co/connecttous/connecttous.html?livedebug...

Thanks for mentioning my project, Reflux.

I initially thought that the suggested implementation by Facebook was a bit weird because it requires a lot of boiler plate code.

For the longest time I disliked using magic strings for type checking since it breaks the concept of polymorphism. In Javascript it is even more weird considering it is a dynamic language. So I fixed that by moving the type specifics (which in Flux's case is mostly about handling events) into the actions and stores themselves.

Thanks to a contributor we also provide a mixin for React components that adds automatic unsubscription on componentWillUnmount and provides a listenTo method in the components to subscribe to actions and stores.

It works both server-side (available at npm) and client-side (available as bower package or can be built in browserify from npm package).

Thanks for posting - I'm glad to learn about reflux here. I started adding flux to an application as prescribed and thought there were many strange and unnecessary steps. All the flux libraries seemed equally complicated. Instead I went with a simple event emitter approach, which is basically Reflux without the nice API. I will certainly give it a try.

We've been exploring Flux pretty heavily here at Yahoo and the idea of utilizing React + Flux stores on the server-side as well. The Yahoo flux-example you linked to is using our own dispatcher (https://github.com/yahoo/dispatchr) that does away with the singleton pattern all of the other Flux documentation and examples have used, making it safe to use on the server.

The React docs talk about this a bit [1]. Have you already tried this? What kind of problems are you encountering?

[1] http://facebook.github.io/react/docs/flux-todo-list.html#add...

Another small attempt using just backbone: https://github.com/shaohua/todomvc-react-flux-backbone

Usually I have an action call out to some DAO class which encapsulates an HTTP request and returns a promise, then just firing off a different action in the done and fail callbacks.

Could you describe what you mean by interdependent actions? As in, chains of actions?

Yes, a chain of actions (for example, a sequence of AJAX requests that need to be fired)

Reply on news.ycombinator.com