Marty.js – A JavaScript library for state management in React applications

1) actions

2) stores.

In Reflux, a store is effectively just a variable you want your component(s) to be able to access and an action is a function that tells the store what to change about its state. For instance, I might have a CurrentUser store that tracks who the current user is and notifies my Profile component when that changes. I might also have a switchUser action that tells CurrentUser to change its state to user #30. That's all you need to understand to use Reflux.

It's certainly interesting to have data fetching baked into Marty, but it also introduces so many concepts. I think it'd be really helpful for people coming from other libraries if you had a big glossary that says what each thing is and why you felt a need to include it. What's a Marty constant and why is it different than an action creator? What purpose does the dispatcher serve? etc.

You'd have a better time recruiting and training new users with a diagram that shows how all these concepts fit together and why you need so many of them.

One cautionary note about how easy it is to integrate React with other frameworks: this statement is true as long as the framework in question doesn't touch the DOM (e.g., using Backbone models). But if you try to integrate React with any JS library or framework that mutates the DOM, you should be aware that this will interfere with React's DOM "accounting" and potentially cause lots of problems.

There are certainly ways around this (look into the lesser-used React life cycles), but it's much easier to stick within the React ecosystem for any libraries that manipulate the DOM, or build your DOM manipulations from scratch (easy to do with React). Already, there's a fairly feature complete React Bootstrap library [2]. I've started work on a React charting library, using d3 for path calculations and other utilities (and temporarily for chart axes generation, but library users shouldn't have to worry about any DOM issues) [3]. And I'm sure there are a thousand and one other React view-level component libraries I'm not familiar with, most of which are likely available via NPM.

But I agree that React and the other virtual DOM libraries and frameworks (Ractive, Mercury, Om, etc.) are the next generation approach for client-side views. They not only make DOM manipulations much snappier, but they also make them much easier for the developer.

1. https://github.com/dustingetz/react-cursor

2. https://github.com/react-bootstrap/react-bootstrap

3. https://github.com/esbullington/react-d3

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 - State Mixins for binding stores to views http://martyjs.org/api/state-mixin/ - State sources for syncing state from heterogeneous sources 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/

Frankly, for small apps, I think you can get 90% of the benefit of Flux by using the pubsub solution of your choice and taking care about only subscribing from top-level components and passing state change down to their children. Immutable cursors are also a nice solution for small apps.

I get that for large teams working on massive code bases, and possibly even for smaller apps, Flux is a big plus. But I'm glad that projects like Marty are working on abstracting out all the boilerplate. Less code for me to worry about.