I've used github/fetch [1] which is a polyfill for the upcoming fetch standard [2]. If you ever want to go beyond this its one of state sources in marty.js [3]
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()
};
}
});
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:
You'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.
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:
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.
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:
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.
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.
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).
Thanks for this. I would most definitely use this on my website. The only thing missing is the ability to add youtube embed code. Any way to make that happen?
[1] https://github.com/github/fetch [2] https://fetch.spec.whatwg.org/ [3] http://martyjs.org/guides/state-sources/http.html