The verboseness is yahoo's is really quite superficial. F.ex. on a day to day basis, you're not spending hours and hours adding action constants.
I've been making an app based on yahoo's dispatchr (part of fluxible) for about 4 months now, and I hardly spend time with the "verbose" part of my app. All the real work is in data fetching, view rendering, business logic, and so on.
Really, if there's X libraries out there and X-1 don't support isomorphic apps, and the only complaint you can come up with about the one that does is that the most boring, logic-free and error-free part of your app will look a little verbose, then what are you still waiting for?
Alt[1] has isomorphic support but there are some trade offs such as you're unable to use actions on the server. But you can still keep your stores as singletons and have them be concurrent. I'm still juggling on different ways to tackle this problem to offer more flexibility. There are a couple of example apps sitting in the iso[2] repo which is an isomorphic helper class.
I've not used flux for my demo, but it is isomorphic, loads data asynchronously (something many isomorphic examples skip over), and has a very simple version of Yahoo's data hydration / dehydration.
I imagine you could extend this to use Flux relatively easily - most of the hard stuff is done, and the code base is quite small.
No reason why it couldn't work on the server: create multiton versions of stores and when a page is ready to be rendered assign the state of the multiton instances to the corresponding singleton instances, call render and return the singleton instances to their previous states. Sure it's hacky as hell but just hide it somewhere, there is no reason to do it manually in application code.
The singletons are only problematic if you need to interact with them asynchronously. `React.renderToString` is synchronous, so there's no reason stores have to be async.
Shameless plug: Fynx[0] is mostly synchronous, for example.
but how would you deal with async data fetches then?
I want to have the same routing and data fetching logic both on the client and on the server, and for that I would need to have stores that are independent for different incoming HTTP requests.
I'm not sure how you're supposed to do it, but that hasn't been a problem for me. I set up two actions: load and init. load starts a request and init sets the data in the store.
Another shameless plug: Flummox deals with this by eschewing singletons https://github.com/acdlite/flummox. Along with built in promise support, it works really well with react-router's lifecycle methods.
Nice to see more singleton free Flux libraries! My experience is also that it's almost impossible to make isomorphic apps with singleton based designs. Too bad the original Facebook version used singletons and everybody copied it. Big mistake.
Btw. I would love to see a full example of an isomorphic Flummox application using react-router.
Yeah absolutely. I'm going to try to work this weekend on some demos. Still trying to figure out a good solution for over-fetching. It's a tough problem... which is why Relay looks so, co cool.
This looks really nice! I haven't understood why this pattern hasn't been the default all along. Singletons are not a pattern used very often in JS so I'm not sure why it caught on in Flux.
Thanks! Yeah, I don't get it either. I think esamatti is exactly right: the original Facebook example used singletons and everyone followed their lead.
That, combined with the fact that all CommonJS modules are singletons, anyway.
All JavaScript modules are singletons regardless of the format. But it's still a very common practice to export a constructor function as the module's value and then to instantiate new instances. No idea why that hasn't been followed with React, but I imagine that you are correct about the Facebook example. They should have put more care into making it correct rather than just making it simple to explain.
- dispatching and listening to actions. you need to pack your action with a magic string and a param object then unpack the params again in every listener. It's easy to forget what the params names are and its hard to see what the function gets as params just from its signature.
It would be much nicer to have e.g.:
context.actions.myAction('foo', 'bar')
And
onMyAction: function(foo, bar)
- dealing with asynchronous data fetches. The example shows that you should create 3 actions for every async data action: FETCH_STARTED, FETCH_COMPLETE and FETCH_ERROR.
How would you deal with cases where you need to fetch multiple data sources then combine them? Seems like the number of actions would quickly explode. Also, how would you deal with dependencies and errors?
- the service api:
context.service.read('message', {}, {}, function (err, messages)
too many optional params, kinda hard to keep track what goes where.
I'd prefer something with promises.
- I also miss query params support in fluxible router
For me, it's really the part where you end up having to wrap up all of your actions with `context.executeAction`.
It would be cool if there was a nice way that you could wrap an action with a function to generate that boilerplate for you, similar to how Bluebird's `Promise.promisify(myFunction)` generates a Promise-wrapped function for anything following the typical Node callback style.
It's great to see more example Flux projects using different implementations, but what we really need is just one larger and more sophisticated app example.
I've been adapting a React-based app to the Flux architecture for the last week or two. I constantly find myself scratching my head, especially regarding asynchronous operations that need to be reflected in the View.
It would be nice for the mock API in these examples to "simulate" a poor network connection in order to see how asynchronous error handling is best handled in each implementation, for instance.
Ha, I actually submitted an issue to this yesterday. It's a good example but misses some really important (i.e. usually-confusing) stuff: error/failure handling and rollbacks.
@prottmann alluded to it, but it might be useful to add Marty as well (http://martyjs.org) (no affiliation).
It's just behind Reflux on the superficial metrics (stars, contributors, npm downloads) so is likely to be on most short-lists.
I've had a good experience with Marty so far but remain curious about the others. Reflux worries me a bit because of its minor divergences from the Flux design decisions.
This is pretty cool. There have been a ton of flux frameworks floating around lately, glad that there's an app that deals with async data to be able to compare each on their merits.
I'm surprised to discover how useful I found this -- being able to compare roughly 'apples to apples' in an app was very helpful. Thank you for your efforts!
To be fair, the word 'reflux' does have significant meaning outside the context of gastrointestinal disease. I agree some people might have unpleasant associations to the word, but for me this is the first thing that comes to mind: https://en.wikipedia.org/wiki/Reflux
Most implementations rely on the flux stores being singletons which can't work for multiple requests on the server.
The only one that's isomorphic is yahoo's but that one feels terribly verbose.