[idbehold]

> But yeah in practice you'd probably not want to slow down the rendering by doing an extra HTTP request so you'd probably send the data to the component in a more synchronous way.

How would you do that without breaking the whole universal/isomorphic aspect of this?

[firasd]

Check my demo using Redux: I populate the "initialState" on the server side [1] before React comes into the picture, and then populate it again on the client side [2], then client-side Redux can do its own thing.

Some explanation at [3] although that writeup (and this demo code) needs updating.

[1] https://github.com/firasd/react-server-tutorial/blob/master/...

[2] https://github.com/firasd/react-server-tutorial/blob/master/...

[3] https://medium.com/@firasd/quick-start-tutorial-universal-re...

[idbehold]

But that means that I need to know which express routes are going to need what data. The react components should be able to declare the data they need and the server should be able to fetch that data before attempting to render server-side. There's not much of a point if I have to know ahead of time what data any react component rendered by a route will need.

[firasd]

I'm not sure 'components declaring the data they need' is a necessary React idiom especially if you're using Flux. But I do understand that any large application will need 'partial' state and you can't fill out the entire app data for every request like I do in my smaller demo apps.

[faceyspacey]

You populate redux with all the data your app needs (if you're using setState to store state fetched from APIs on components, stop). Then you simply render your app in one go.

[idbehold]

Okay, let's say I put the actual fetch() inside a redux "action creator" how am I fetching that data server-side? How does some arbitrary route know that a nested component needs to fetch() and then populate your store before rendering? And remember, the fetch() in the "action creator" is still trying to hit a relative route.

[faceyspacey]

you call the action creator and dispatch its results to you redux store before rendering. For "arbitrary" routes, you design your application in a way that just by the pathname, query parameters, etc, you know exactly what data to get for the whole component tree. ..Don't use a relative route.

[idbehold]

> For "arbitrary" routes, you design your application in a way that just by the pathname, query parameters, etc, you know exactly what data to get for the whole component tree.

That entirely defeats the purpose of an isomorphic/universal React application.