Hacker News Reader

Comment by acdlite | Hacker News Reader

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.

View on HN

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.

You can see an example of Fluxible with react-router: https://github.com/yahoo/flux-examples/tree/master/react-rou...

Whipped together a basic one last night: https://github.com/acdlite/flummox-isomorphic-demo

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.

Yep, that's what I was trying to say. The require cache makes the singleton pattern extra alluring, even in cases where you should avoid it.

Reply on news.ycombinator.com