A few of the flux implementations have the concept of "rehydrating" state (serializing and deserializing the stores), which does allow the client side to reuse the data and keeps the component from refetching the data.
A useful pattern I discovered was fetching just what is necessary to render the page on the server. Then pass the state to the window object through a script tag and recover the data on the client side and rehydrate. Any additional data (or potentially slow returning), I fetch client side via `componentDidMount` [0] which isn't called on the server. This way, I can get a loading screen up as quickly as possible with a few elements custom to the user.
I should note that even thought the flux library I was using, flummox [1], works great for this, I can't recommend it as in the month and a half I was working on my project they've decided to quit and recommend a different library, so I'm not sure what to recommend now (the frustration I feel over this quick turnaround is an entirely separate topic, though).
Depending on the kind of content t you have, that's hardly an issue. I've built a big site like this, and gzip does an extremely good job at filtering out duplicate data. Check the source of http://viva.vlaanderen/
when you view the source of your page, you see that very little of the dehydrated state is used to build your initial markup.
The entire rendered source is 142K. I isolated the actual markup, and it weighs in at 31K.
In other words, your dehydrated state is 4x bigger than your html rendering. And that's not including your 750K main.js file that also gets downloaded.
That's almost 1MB of downloads (not including images and stylesheets) just to "app-ify" your 31K of markup. I tend to agree, it's not a problem. Or perhaps, it's not one of the biggest problems. But it's not "hardly an issue" either.
A useful pattern I discovered was fetching just what is necessary to render the page on the server. Then pass the state to the window object through a script tag and recover the data on the client side and rehydrate. Any additional data (or potentially slow returning), I fetch client side via `componentDidMount` [0] which isn't called on the server. This way, I can get a loading screen up as quickly as possible with a few elements custom to the user.
I should note that even thought the flux library I was using, flummox [1], works great for this, I can't recommend it as in the month and a half I was working on my project they've decided to quit and recommend a different library, so I'm not sure what to recommend now (the frustration I feel over this quick turnaround is an entirely separate topic, though).
0: https://facebook.github.io/react/docs/component-specs.html#m...
1: http://acdlite.github.io/flummox
2: https://github.com/acdlite/flummox#40-will-likely-be-the-las...