[bsimpson]

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.

[jfhollingworth]

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

[bsimpson]

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.