Author here. 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/

Like many others, I've been using Reflux because it seems to be the easiest to understand and to work with by reducing the surface area of concepts you need to understand to just:

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.

That's what I tried to do with this page http://martyjs.org/guides/flux/index.html. Let me know how I could improve it

I see a Get Started Now button on the home page (I didn't see it the first time through). I'd add a How It Works button right next to it that links to that Flux page. It's definitely helpful, although the constants and dispatchers feel like implementation details that most developers shouldn't have to think about.

You switch between "actions" and "action creators" in this paragraph, which makes it hard to follow:

> Action Creators are where any changes to your applications state starts. Actions are functions that are responsible for coordinating changes to local and remote state. Actions have a type which is a string describing the action (e.g. "UPDATE_USER_EMAIL").

I thought the Action Creator was a function and the Action was the act of invoking it, but that's not clear in the quoted section.

-----

I think your documentation is a bit hard to follow because you're using JavaScript in unexpected ways. For instance, it's a bit weird that your constants are invokable:

    updateUserEmail: UserConstants.UPDATE_USER_EMAIL(function (userId, email) {

and I think the line after it mixed constants and action creators:

> In the above scenario, UserConstants.UPDATE_USER_EMAIL creates an action creator which, when invoked, will create an action with type UPDATE_USER_EMAIL.

-----

You're missing a ( here:

    UserActionCreators.updateUserEmailthis.props.userId, email);

-----

In the next example, you use the method name as a key and the constant that triggers it as a value:

    handlers: {
      updateEmail: UserConstants.UPDATE_USER_EMAIL
    },

Since the convention in all the libraries I've seen is to use type as the key and the callback as the value, most developers are going to be immediately tripped up by this unless you call it out in the documentation.

-----

Marty has some interesting ideas. Thanks for sharing them, and for taking the time to make a website explaining them.

Thanks, i will have a closer look.

The integrated data fetching and data flow extension sounds interesting, at the moment i use superagent with the mentioned callbacks and events to visualize (it is not comfortable).

A first look at the examples for both projects would give you that impression.

Some areas that Marty differs in: - State sources: http://martyjs.org/api/state-sources/index.html - Contants are handled more intelligently: http://martyjs.org/api/constants/index.html - Dev tools: http://martyjs.org/devtools/