Implement in react-redux-universal-hot-example

[quicksnap]

There's some talk about this library in erikras/react-redux-universal-hot-example#439

Would you be interested in starting a branch to integrate this library as a replacement? It could serve as a good example on how to migrate from redux-router to redux-simple-router, and could uncover pain points along the way.

I'd be happy to help, too. But for the next few days, probably not much.

If you think it would not serve as a good replacement, that would be great information, too!

[jlongster]

That would be an interesting experiment, and I'm sure I'd learn a few things about why redux-router works the way it does. I don't think I'll have time to do it in the next few days (not really familiar with it) but I'll keep this issue open and maybe next week I can take a shot.

[quicksnap]

Totally--I'm interested too, but pretty busy myself. I haven't personally run into any issues with redux-router in my project, so it's low priority for my own needs.

[jlongster]

Alright, I did an initial port here: jlongster/react-redux-universal-hot-example@e13b935?diff=split

Who else should I loop in? @stevoland @erikras @justingreenberg? I'll play around with it for a few more days.

It's more elegant IMHO. Particularly server-rendering. No more hacks to store the data fetching promise on the state or anything like that. The state should stay pure. You can just use react-router straight up.

[quicksnap]

Looks good at first glance--thanks for doing this!

I'll try and take a look tomorrow and port it into my project.

[bendiy]

@jlongster Thanks for putting this together so quickly. I was struggling with redux-router and this approach seems much simpler.

I found a small change here:
jlongster/react-redux-universal-hot-example@e13b935?diff=split#commitcomment-14335312

[Dattaya]

@jlongster dispatching during this stage gave me this warning on the client while transitioning: Warning: setState(...): Cannot update during an existing state transition (such as within render). Render methods should be a pure function of props and state. What about you, did you test your code?

[erikras]

If you guys could kick the tires on this a bit more, I'd love to merge it.

[quicksnap]

I definitely think we should test this out for about a week before merging, just to make sure! But looks great.

[jlongster]

Will kick around some more soon, been a busy week at work. @Dattaya thanks for the report.

[louissmit]

I think fetchDataDeferred stopped working in @jlongster 's port? Like when you route to /widgets

[stevoland]

@louissmit I think fetchData becomes the equivalent of fetchDataDeferred as it no longer blocks rendering of the container: jlongster/react-redux-universal-hot-example@e13b935?diff=split#diff-cf27c1d543e886c89cd9ac8b8aeaf05bR39 This is fine as far as I'm concerned.

Looks great! I'm starting a project right now and this is going in for sure.

[louissmit]

@stevoland I'm not sure I see how it no longer blocks, but in either case the widgets example is broken in its current implementation.

I'm new to this boilerplate and redux so I'm just trying to figure out how it works. (:

[jlongster]

@louissmit haven't had a chance to flesh all this out yet, this week has been busy. I'm going to work on it some this weekend.

On the client-side, it does not block, but that's just the strategy I chose for now. It we want it to block to emulate the previous behavior, we just need to use onEnter which has a 3rd callback argument.

[quicksnap]

Glad to hear @stevoland likes this! I think I'll have some time today to try it. My project relies on both fetchData and fetchDataDeferred, so if I can get it working I'd be stoked!