search

ericclemmons / react-resolver

Async rendering & data-fetching for universal React applications.
https://ericclemmons.github.io/react-resolver
Other
1.65k stars 52 forks source link

Usage for flux #94

Open khankuan opened 9 years ago

khankuan commented 9 years ago

Hi, was thinking if there is a better way to use resolve. I'm using it to trigger actions that will populate stores instead of setting a prop on resolve.

ericclemmons commented 9 years ago

Right, and this is where flux-like implementations such as Redux kinda "break" here.

The original purpose of this lib was to be flux-agnostic and allow lazy-loading missing props for a component.

No worries, though. I have a semi-working Redux + Resolver implementation in a work project that replaces @connect with @reconnect (see what I did there?) that fits with Redux's "fire an action, but the return value isn't really what you want" craziness.

khankuan commented 9 years ago

Sounds great :D Would look forward to that in the roadmap.

adamscybot commented 8 years ago

@ericclemmons That is pretty much exactly what I'm looking for. Was there any progress? As you outline, the trouble with libs like react-transmit, react-resolver and async-props is that they all provide props that are the resolved return value of the async function. If you have signed up to the "single source of truth state tree" mantra of redux then this is incompatible as the async function is just an action to trigger manipulating that tree.

ericclemmons commented 8 years ago

Adam, you're correct. And yes, this is largely solved (but missing some more isomorphic tests) that I'll have wrapped up for the holidays. React Resolver will be updated for formal v0.14 support (deprecating v0.13), but redux-reconnect will be the replacement in your Redux apps to convert them into fully isomorphic, SSoT apps.

On Fri, Dec 18, 2015 at 10:44 AM Adam Thomas notifications@github.com wrote:

@ericclemmons https://github.com/ericclemmons That is pretty much exactly what I'm looking for. Was there any progress? As you outline, the trouble with libs like react-transmit, react-resolver and async-props is that they all provide props that are the resolved return value of the async function. If you have signed up to the "single source of truth state tree" mantra of redux then this is incompatible.

— Reply to this email directly or view it on GitHub https://github.com/ericclemmons/react-resolver/issues/94#issuecomment-165831633 .

  • Eric Clemmons
adamscybot commented 8 years ago

Great news! Look forward to trying it out :).

leebenson commented 8 years ago

apologies for the +1, but just wondering if there was any progress on this?

I'm using Redux, and looking for a simple way to fire a bunch of actions (that all return promises) per component and await those promises before sending back the initial SSR.

In that scenario, I don't care about return values or adding to this.props because Redux is already passing the store, which represents the entire app state. It sounds like your @reconnect implementation would fit this perfectly.

I'm really surprised the rest of the Redux community hasn't come out with something to address this, TBH. Seems like a really obvious need. Alas, if you have an update, that'd be awesome -- I'm on the verge of writing a home-brew hack but I'm sure yours would be a lot better!

ericclemmons commented 8 years ago

I agree, and I'm sorry I haven't completed it. It's been a few months of trying to get a major project out the door and, luckily, we don't require SSR.

In the meantime, I'd recommend trying out https://github.com/markdalgleish/redial.

It's very similar to @reconnect. The major difference would be not having to manually perform dispatches. @reconnect tries to let your app "fill in any blanks" but ideally never has to run.

On Sat, Feb 20, 2016 at 11:37 PM Lee Benson notifications@github.com wrote:

apologies for the +1, but just wondering if there was any progress on this?

I'm using Redux, and looking for a simple way to fire a bunch of actions (that all return promises) per component and await those promises before sending back the initial SSR.

In that scenario, I don't care about return values or adding to this.props because Redux is already passing the store, which represents the entire app state. It sounds like your @reconnect https://github.com/reconnect implementation would fit this perfectly.

I'm really surprised the rest of the Redux community hasn't come out with something to address this, TBH. Seems like a really obvious need. Alas, if you have an update, that'd be awesome -- I'm on the verge of writing a home-brew hack but I'm sure yours would be a lot better!

— Reply to this email directly or view it on GitHub https://github.com/ericclemmons/react-resolver/issues/94#issuecomment-186749376 .

  • Eric Clemmons
leebenson commented 8 years ago

redial looks perfect, thanks so much for the suggestion @ericclemmons - appreciate you taking the time to help.