Hacker News new | ask | show | jobs
by colinramsay 4173 days ago
I'm scanning the documentation for this now and the "state sources" concept looks useful. Stores seem to be a bit cleverer than in other Flux implementations too.

The fact it's got a Chrome extension and what appears to be comprehensive documentation bodes well. I'm currently using reflux because I like its simplicity (no dispatcher and no action creators) but Marty has definitely piqued my interest.

Edit: Question for the author. Any thoughts on isomorphic apps with Marty? Edit2: Answering my own question: https://github.com/jhollingworth/marty/issues/13

2 comments

Isomorphic apps are the next big challenge. Right now the biggest blocker is that everything's a singleton. I'm working on an internal container which should hopefully mean existing apps can be made isomoprhic without a change to the API
I've found that contexts are a good way to handle this - they're basically invisible props that get implicitly passed down the component tree, and mixins can whitelist which parts of the context they want to be able to use. They're undocumented, but they're used quite widely in React, so I doubt they're going anywhere. You can have a top-level component instantiate new dispatchers and stores and expose them as i.e. "this.context.userStore", "this.context.dispatcher" to mixins and component code. And this can be done concurrently in the same Node process without needing VMs/sandboxing. Your state mixin API might need to change a bit, but it can be substantially the same:

var UserState = Marty.createStateMixin({ listenTo: "UserStore", getState: function (UserStore) { return { users: UserStore.getAll() }; } });

A reference: https://www.tildedave.com/2014/11/15/introduction-to-context...

Fluxxor, FYI, bundles all of this in context.flux: https://github.com/BinaryMuse/fluxxor/blob/master/lib/flux_m...

General impression is the same. I'm using Reflux and quite happy with it, but this does seem pretty smart. Having built in rollback of actions is nice, and having the versatility of where-queries to invoke action handlers is interesting. Not sure if its worth the switch, there aren't really pain points to be solved here... but my next React project might use this.