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 :)
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.
Hey Elie! Not directly, no. It looks like both of our projects originated from "real world apps" (as you say) with SEO requirements and, in my case in particular, ensuring mobile users get a response ASAP before React progressively enhances the page.
It looks like we've landed on about the same architectural solution given React's synchronous nature.
I'll have to check it out in more detail as, to be honest, I was more aware of the Nexus Flux library.
This is nice but I can imagine it would still require a lot of boilerplate code in order to integrate nicely into a flux architecture in a production app. Comparatively, I think Fluxible does a good job in separating the async logic while providing you with clean Flux terms. Would be interested to see some higher-level integration library with Redux, Alt or a flux library.
It's not much more than an additional 1 or 2 decorators, & even those can be a local file specific to how you write your app. In my experience, I only add a `@dispatcher()` decorator above it, and use `@resolve` as normal. 1 line doesn't constitute "a lot of boilerplate" in my opinion :)
I intentionally didn't couple this with a specific Flux lib since _this solves an entirely different problem_ than maintaining application state.
Look forward the Redux & Alt example, though, as those will have a very terse, so you won't have to use your imagination anymore!
10 comments
[ 3.3 ms ] story [ 25.7 ms ] threadThis 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 :)
How you choose to fetch data is up to you, whether you use Flux, or fire AJAX calls within the `@resolve` function.
That's your code, not mine. I just make it so you can put your data requirements _beside_ your component instead of several layers up :)
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.[1] https://github.com/elierotenberg/react-nexus
It looks like we've landed on about the same architectural solution given React's synchronous nature.
I'll have to check it out in more detail as, to be honest, I was more aware of the Nexus Flux library.
I intentionally didn't couple this with a specific Flux lib since _this solves an entirely different problem_ than maintaining application state.
Look forward the Redux & Alt example, though, as those will have a very terse, so you won't have to use your imagination anymore!