9 ms·

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

by d4n3 12y 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.

ksmtk 12y ago
I completely agree that Fluxible feels very verbose.. Did you try Reflux.js?
- amirouche 12y ago
  reflux.js isomorphic support is still in flux https://github.com/spoike/refluxjs/issues/144 https://github.com/spoike/refluxjs/issues/144
- redonkulus 12y ago
  (fluxible dev here) Which part of Fluxible feels verbose?
  - clarle 12y ago
    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.
  - d4n3 12y ago
    - 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
DougBTX 12y ago
There's another demo here: https://github.com/zertosh/ssr-demo-kit https://github.com/zertosh/ssr-demo-kit
goatslacker 12y 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 https://github.com/goatslacker/alt 2: https://github.com/goatslacker/iso/tree/master/examples https://github.com/goatslacker/iso/tree/master/examples
skrebbel 12y 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?
pluma 12y 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 https://www.npmjs.com/package/fynx
- bryanlarsen 12y ago
  Fynx is what I'm using in my project. It'd be nice to get it added to the comparison.
- deleted 12y ago
  [deleted]
- ksmtk 12y ago
  Stores should be definitely sync in any implementation!
- d4n3 12y 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.
  - bryanlarsen 12y ago
    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.
acdlite 12y ago
Another shameless plug: Flummox deals with this by eschewing singletons https://github.com/acdlite/flummox https://github.com/acdlite/flummox. Along with built in promise support, it works really well with react-router's lifecycle methods.
- esamatti 12y 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.
  - acdlite 12y ago
    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.
  - redonkulus 12y ago
    You can see an example of Fluxible with react-router: https://github.com/yahoo/flux-examples/tree/master/react-router https://github.com/yahoo/flux-examples/tree/master/react-rou...
  - acdlite 12y ago
    Whipped together a basic one last night: https://github.com/acdlite/flummox-isomorphic-demo https://github.com/acdlite/flummox-isomorphic-demo
- Touche 12y 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.
  - acdlite 12y ago
davedx 12y 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 https://github.com/davedx/isomorphic-react-template
bringking 12y ago
I am using Yahoo's fluxible app and it is quite good. Doesn't feel verbose at all in every day use.
esailija 12y 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 12y ago
Here's a demo I put together: https://github.com/appsforartists/ambidex-example--bike-index/tree/master/application/bike-index/reflux 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.

by d4n3 12y ago

ksmtk 12y ago

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

amirouche 12y ago
reflux.js isomorphic support is still in flux https://github.com/spoike/refluxjs/issues/144 https://github.com/spoike/refluxjs/issues/144
redonkulus 12y ago
(fluxible dev here) Which part of Fluxible feels verbose?
- clarle 12y ago
  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.
- d4n3 12y ago
  - 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

DougBTX 12y ago

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

goatslacker 12y 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 https://github.com/goatslacker/alt 2: https://github.com/goatslacker/iso/tree/master/examples https://github.com/goatslacker/iso/tree/master/examples

skrebbel 12y 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?

pluma 12y 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 https://www.npmjs.com/package/fynx

bryanlarsen 12y ago
Fynx is what I'm using in my project. It'd be nice to get it added to the comparison.
deleted 12y ago
[deleted]
ksmtk 12y ago
Stores should be definitely sync in any implementation!
d4n3 12y 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.
- bryanlarsen 12y ago
  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.

acdlite 12y ago

Another shameless plug: Flummox deals with this by eschewing singletons https://github.com/acdlite/flummox https://github.com/acdlite/flummox. Along with built in promise support, it works really well with react-router's lifecycle methods.

esamatti 12y 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.
- acdlite 12y ago
  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.
- redonkulus 12y ago
  You can see an example of Fluxible with react-router: https://github.com/yahoo/flux-examples/tree/master/react-router https://github.com/yahoo/flux-examples/tree/master/react-rou...
- acdlite 12y ago
  Whipped together a basic one last night: https://github.com/acdlite/flummox-isomorphic-demo https://github.com/acdlite/flummox-isomorphic-demo
Touche 12y 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.
- acdlite 12y ago

davedx 12y 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 https://github.com/davedx/isomorphic-react-template

bringking 12y ago

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

esailija 12y 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 12y ago

Here's a demo I put together: https://github.com/appsforartists/ambidex-example--bike-index/tree/master/application/bike-index/reflux 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.