It works very well! React Resolver is handling the async-loading & rendering problem for you. How you choose to fetch & update data within your components is up to you :)
I have a very large application in production now using a custom flux implementation (since the flux wars have finally died down Alt & Redux taking the lead).
There'll be some documentation & examples around Redux specifically, but the gist is you'd do something like this (not using any Flux library in particular here):
// Flux - watch UserStore for changes & provide "props.userStore".
@connectToStore(UserStore)
// Flux - provide actions as props for the resolver or component to use.
@bindActions(function(dispatcher) {
return {
create: dispatcher.actions.User.create,
save: dispatcher.actions.User.save,
};
})
// Resolver -
@resolve("user", function({ create, userStore }) {
return userStore.getCurrent() || create("New User");
})
// Now your component always has the latest, updated user
export default UserProfile extends React Component {
Watch the repo for some more examples, as there'll be both Alt & Redux examples.
You're correct in that Relay correctly identified the same architectural problem with having data requirements _far away_ from the components that actually need it.
This is why React Resolver was created, and from what I've seen, also spurred React Nexus & React Transmit as well.
On an related note, v1 of React Resolver explicitly stated how it was similar to Relay with regards to fetching data for components. I've since dropped that messaging to avoid confusion since Relay isn't even available yet :)
I have a very large application in production now using a custom flux implementation (since the flux wars have finally died down Alt & Redux taking the lead).
There'll be some documentation & examples around Redux specifically, but the gist is you'd do something like this (not using any Flux library in particular here):
Watch the repo for some more examples, as there'll be both Alt & Redux examples.