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!
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.
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.
[+] [-] syedatif|10 years ago|reply
[+] [-] ericclemmons|10 years ago|reply
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!
[+] [-] elierotenberg|10 years ago|reply
[1] https://github.com/elierotenberg/react-nexus
[+] [-] ericclemmons|10 years ago|reply
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.
[+] [-] mtschopp|10 years ago|reply
[+] [-] ericclemmons|10 years ago|reply
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.[+] [-] mike-cardwell|10 years ago|reply