Flux Comparison by Example

https://github.com/voronianski/flux-comparison

by ksmtk • 11 years ago

145 55 11 years ago

bhouston• 11 years ago

Where do people think up these names: Reflux? http://en.wikipedia.org/wiki/Gastroesophageal_reflux_disease

Why don't we have a library called Melanoma or HIV yet? Actually I am sure we do have libraries with these names somewhere on github.

ksmtk5• 11 years ago

haha that's funny! because recently I had reflux disease :)

jvdp• 11 years ago

Well, there's Mono...

mhd• 11 years ago

A language runtime for Unix systems...

felixvolny• 11 years ago

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

FLUX-YOU• 11 years ago

Who knows? Bunch of cheeky bastards with a flux capacitor obsession really.

pluma2• 11 years ago

As someone suffering from non-erosive esophageal reflux disease (N.E.R.D., btw), I take no offense from one of the libraries being called Reflux.

Drama much?

gagege• 11 years ago

It gives me an uneasy feeling too. It's slightly better than calling a library Vomit.js.

smackfu• 11 years ago

Bigger issue is that utility f.lux.

Semiapies• 11 years ago

I once saw someone rant for pages and pages about how "flux" was a terrible name for anything because it was an archaic term for diarrhea.

goatslacker2• 11 years ago

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.

prottmann• 11 years ago

Thank you! Yesterday i thought about something similar -> a comparison of different flux implementations with an example (and not with a todo-app).

I tried some sample apps in the last weeks with reflux, fluxxor and now marty to see the practical differences.

Narretz• 11 years ago

Is there a formal spec for a "flux application"? Or what's the common denominator here?

DougBTX2• 11 years ago

Closest is probably http://facebook.github.io/flux/docs/overview.html

d4n33• 11 years ago

Anyone tried doing isomorphic (server/client) flux?

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.

ksmtk5• 11 years ago

I completely agree that Fluxible feels very verbose.. Did you try Reflux.js?

amirouche• 11 years ago

reflux.js isomorphic support is still in flux https://github.com/spoike/refluxjs/issues/144

redonkulus2• 11 years ago

(fluxible dev here)

Which part of Fluxible feels verbose?

DougBTX2• 11 years ago

There's another demo here: https://github.com/zertosh/ssr-demo-kit

goatslacker2• 11 years ago

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.

1: https://github.com/goatslacker/alt

2: https://github.com/goatslacker/iso/tree/master/examples

skrebbel• 11 years ago

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?

pluma2• 11 years ago

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.

[0] https://www.npmjs.com/package/fynx

bryanlarsen2• 11 years ago

Fynx is what I'm using in my project. It'd be nice to get it added to the comparison.

ksmtk5• 11 years ago

Stores should be definitely sync in any implementation!

d4n33• 11 years ago

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.

acdlite5• 11 years ago

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.

esamatti• 11 years ago

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.

Touche2• 11 years ago

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.

davedx• 11 years ago

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.

https://github.com/davedx/isomorphic-react-template

bringking• 11 years ago

I am using Yahoo's fluxible app and it is quite good. Doesn't feel verbose at all in every day use.

esailija• 11 years ago

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.

bsimpson• 11 years ago

Here's a demo I put together:

https://github.com/appsforartists/ambidex-example--bike-inde...

It instantiates a new Reflux store for each request, and uses data in the URL to figure out which stores to populate before rendering.

hleszek• 11 years ago

So, which one do you prefer and why ?

hoodoof• 11 years ago

Is there a conclusion, comparison or a point? I'm interested in the outcome but not trawling through the links and stuff.

ksmtk5• 11 years ago

there will be summing up article soon, but that's not the main point

cies• 11 years ago

I would also like your know thoughts on how they compare.

danesparza• 11 years ago

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!

Ronsenshi• 11 years ago

Great job! It's nice to be able to compare same application elements written in different frameworks - very illustrative.

Can't wait for the post with conclusion and thoughts on this.

mukmuk• 11 years ago

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

uxtemple• 11 years ago

Same thing here. Marty is proving to be very good and flexible so far while providing a rather succinct implementation overall. +1

jfhollingworth2• 11 years ago

I've opened a PR for it but it needs to be merged in https://github.com/voronianski/flux-comparison/pull/5

ksmtk5• 11 years ago

marty example is added to repo - https://github.com/voronianski/flux-comparison/tree/master/m...

mercer• 11 years ago

Could you elaborate on your worries? I've used Reflux because it simplified certain things, and I'd love to understand the drawbacks.

namuol2• 11 years ago

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.

jfhollingworth2• 11 years ago

That's why we created https://github.com/jhollingworth/marty-chat-example. It's got proper examples of using HTTP & WebSockets

namuol2• 11 years ago

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.

Flux Comparison by Example

Related Stories