Hacker News Reader

Comment by girvo | Hacker News Reader

> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server.

We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stores, tonnes of actions and a large number of components).

With Flummox making it so easy, we put all state into a store. This allows us to save application UI state to localStorage, bootstrapping the app into the same position the user was previous, with again no extra effort on our behalf. It's well worth checking out!

[0] http://acdlite.github.io/flummox/

View on HN

Flummox is incredible, and pretty much the first thing I point beginners to after they've learned the basic concepts of flux (I don't even show them Facebook's implementation because it's actually pretty poor and relies heavily on singletons and interacting directly with things that should be implementation details like the dispatcher)

Gosh yes, Facebooks implementation doesn't really do the whole idea justice to be honest. Alt and Flummox are much nicer, but I found Flummox far easier to use; one of the few libraries that seems to strike the balance between minimalism and features. I'm definitely impressed, and it was a super easy sell at work to move to a "three tier" architecture, because two of those tiers are the same code base with Flummox and React!

I wonder how everyone takes care of error handling in Flummox (or Flux in general)? Would you also trigger an action, then wait for the store to set some sort of error state?

Basically, how would you migrate the following code to Flux:

  click() { doAction().catch(err => showModal(err)) }

Great question! Actions should be thought of as a mapping between some mechanical UI event (typing in a form, clicking on a button) and an event with some meaning in your application ("user typed a hacker news comment", "user submitted a reply to this comment with this text"). Whatever your application data store abstraction is, it should be responsible for taking that meaningful event and figuring out what to do with it (check to see that the message isn't empty, check to see that the comment was persisted to the server).

Actions describe things that happened in the world and the role of your store is to figure out if that thing that happened is valid or not, and pass the necessary data to components listening for changes.

Thanks for your explanation, that makes sense theoretically but... could you provide a code example for how this breaks out in practice?

I guess what s/he meant was having something like this in the store:

  handleComment(comment) { 
    if (comment === '') this.dispatch('comment-error', 'empty')
    else svc.send(comment)
            .then(() => this.dispatch('comment-success')
            .catch(err => this.dispatch('comment-error', err))
  }

The view/controller (or whatever it's called in React) will then listen to the events and set its state accordingly so that the UI can be re-rendered.

It does look quite complicated compared with typical error handling code. Not sure if I misunderstood something or whether this additional layer of message dispatching is worthwhile in most apps.

What does isomorphism mean here? I know what it means in mathematics, but the explanation in flummox site does not compute for me.

In React / Javascript land, isomorphism means, "the same code is used to render on the server and in the browser"

It's a term used to refer to applications that run some of the same code client-side and server-side. See: http://isomorphic.net/

I really really hope the JavaScript redefinition of this word dies out. Please just make a new word instead of butchering a perfectly well-defined one.

I don't disagree, I come from a maths background so it's a bit weird too; however, I'm yet to see a decent alternative and it's rather entrenched now. It's not a good descriptor however: using the word with non-tech product owners makes their eyes glaze over, so I'd love something better but am yet to come across it.

It's using the completely correct biology usage: "a similarity of form or structure between organisms"

Thinking it only refers to one field and is wrong - when the usage is totally correct (and very applicable) just makes you sound snobbish... and foolish.

Oh holy shit I just moved my app off of reflux and on to flummox and wow! Much better

What would you say the major differences are with Flummox? It looks pretty straightforward but Reflux seems pretty lightweight as well. Just trying to figure out if it's worthwhile to switch an early stage project over.

I would say that Flummox is a slightly more verbose Reflux, written in a way that is somewhat more future proof and adaptable to change.

For the past one month, I've been working on an app in Reflux. If the benefits are significant, I'd surely look at switching to Flummox. Care to point out how the switch has been useful to you?

Thanks!

I like very much that the API is more "standard" (reflux, imo, has some strange patterns) -- also, due to the ability to instantiate every aspect of the pipeline, you get isomorphism for free, and testing is much, much simpler.

Also, can't hurt that the library was designed and implemented in ES6, which is what I've begun moving our architecture towards!

Well pretty much Flummox is ES6-ified Reflux, no big differences in functionality...

I'm also curious to hear why you like Flummox better than Reflux. I'm using Reflux now, and haven't hit any pain points, which I can't say the same about some of the other Flux implementations.

When I started investigating isomporphic strategies with Reflux I stumbled upon this thread (https://github.com/spoike/refluxjs/issues/144) which made me realize that if I didn't switch quick I would have some terrible technical debt on my hands in the coming months. I started looking for alternatives and found Flummox, which is lightweight, isomorphic, and written for the future via ES6-7 features like async await and classes. (Once you start using ES6 classes with ES7 classProperties turned on via Babel -> stage 0 you'll never want to go back to the old way of writing things.)

This is probably obvious but why is the existence of singletons what destroys "isomorphism"?

Because that singleton will serve multiple requests on the server, requests from different users. Singletons are more okay on the client because you know you'll only serve one user, so the singleton can make that assumption as well. But that doesn't work on the server, since the singleton is serving more than one user.

You can still use singletons on the server, but you have to pass the current user id to every method/event on that singleton. And that ends up being quite annoying.

Ah, I see. Thanks.

On the serverside, your stores should not be singletons (shared between all requests) but in request scope (one per request). Otherwise users will be reading eachother's data.

Has anyone built their app using ES5 and Flummox? The Flummox documentation is sparse to start and is completely devoid of ES5 examples.

Edit: grammar.

I struggled the same with another ES6-first library. The best way to convert those to ES5 is via copy / pasting the code in https://babeljs.io/repl/. After a while, you'll quickly learn the syntax and the code will come naturally.

Why not write in ES6 and transpile downwards to ES5? You're just fighting the direction of the wind otherwise. ES6 feels much, much nicer to work with in nearly all ways.

We rolled our own Flux library before they published any code, dodging singletons and gaining mock-free testability. I just re-wrote it, but will check Flummox out.

I had been using reflux when trying out react native. This actually looks nicer than reflux, i think i'll check it out :)

Reply on news.ycombinator.com