erikras / react-redux-universal-hot-example

A starter boilerplate for a universal webapp using express, react, redux, webpack, and react-transform
MIT License
12k stars 2.5k forks source link

[help] animating to a new route/view #837

Open cuzzo opened 8 years ago

cuzzo commented 8 years ago

Hey @erikras,

First of all, this example is awesome! So much so that it's made me greedy to get even more out of it [=

I've been trying to figure out where the in source I would add functionality so that when a user changes the route (clicks a link), the page animates to the next screen, while the API request happens in the background.

The tricky part for me is that I don't want the page to re-render until BOTH the API request is returned and the animation has finished.

The abstraction for fetching data and doing something on success or failure is pretty nice, but I'm having trouble jamming a blocking animation into the mix.

Thanks!

quicksnap commented 8 years ago

Within a route, such as App.js, you can wrap parts of render in an animation utility such as React's CSSTransitionGroup. I've had success wrapping this line: https://github.com/erikras/react-redux-universal-hot-example/blob/master/src/containers/App/App.js#L112

quicksnap commented 8 years ago

I'm not clear on the specifics of your use case though--If you have an API call being triggered in fetchData, it should block the route transition until it's complete. Then, your CSSTransitionGroup will do its work.

I know having animations start when another finishes can be a pain in the ass. There's some timer stuff with CSSTransitionGroup that can be toyed with.

cuzzo commented 8 years ago

Hey @quicksnap,

The animation isn't the problem. I've figured that out.

Timing is my problem. I need the API call on the client to take at least as long as the animation before it changes the route. I think something as simple as adding an additional parameter to fetchData for the minimum time it can take would work--considering I can have it only take that minimum time on the client. I'd still want the server to return as fast as possible.

But thanks for the heads up on where to start. I've got a few ideas. None of them seem right, though /=