5 ms·
Hey, author here. This is a repeat of my answer below but it's right down the bottom so might be missed: I found that no other Flux implementation really helpe
by jfhollingworth 12y ago
Hey, author here. This is a repeat of my answer below but it's right down the bottom so might be missed:
I found that no other Flux implementation really helped with fetching data in a Fluxy way. There tended to be a lot of boiler plate code for binding stores to components. Furthermore, there was a lack of tooling for debugging. Marty helps combat these issues by introducing a number of new things:
- Fetch API for fetching data asynchronously without callbacks http://martyjs.org/guides/stores/fetching-data.html http://martyjs.org/guides/stores/fetching-data.html
- State Mixins for binding stores to views http://martyjs.org/api/state-mixin/ http://martyjs.org/api/state-mixin/
- State sources for syncing state from heterogeneous sources http://martyjs.org/guides/state-sources/index.html http://martyjs.org/guides/state-sources/index.html
- Chrome Developer extension (beta) for visualising the data flow and state of stores http://martyjs.org/devtools/ http://martyjs.org/devtools/
- picardo 12y agoYou're right about the boilerplate. I use a wrapper around React.createClass to take care of that. Kinda similar to Marty.createStateMixin, but it's just a component factory. The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store. It's a nice to have, but not filling a need for me.
- catshirt 12y ago> The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store. by that logic, you don't need a debugger with breakpoints and stack traces either. i mean... you could use a spoon for driving nails into wood instead of a hammer, too.
- picardo 12y agoI could also use a jackhammer, but that's not what jackhammers are for.