4 ms·

What is the argument for going completely static? Static as in not using React on the client, not as in static files. It seems (to me), that it would be useful

by vkjv 11y ago

What is the argument for going completely static? Static as in not using React on the client, not as in static files. It seems (to me), that it would be useful--in addition to the static html--load React on the client and from that point navigate with push state and small static (JSON?) files. It might perform better if your blog has a lot more interactivity. Although, here I can definitely see that as being fluff.

jacquesm 11y ago
Speed, simplicity, security.
- sergiotapia 11y ago
  Synergy.
  - cozuya 11y ago
    SEO
    - vkjv 11y ago
      This doesn't make sense. You can still generate all of the HTML with react tags for SEO. The difference, is you can still use React in the client after page load.
dugmartin 11y ago
I played around with building something similar. The problem becomes that you have to send down twice the amount of data for the page - the statically rendered html generated from your data and then the data itself so that when the React components mount their props/state match the statically generated html.
- bryanlarsen 11y ago
  The easy fix for that is to send the data asynchronously in a separate request. It takes a little longer for the page to go "live", but the static part is functional quicker. A harder fix is to walk the static DOM to inflate your store. It shouldn't be too hard since you can add hints to the DOM to guide your parser.
- adregan 11y ago
  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). 0: https://facebook.github.io/react/docs/component-specs.html#mounting-componentdidmount https://facebook.github.io/react/docs/component-specs.html#m... 1: http://acdlite.github.io/flummox http://acdlite.github.io/flummox 2: https://github.com/acdlite/flummox#40-will-likely-be-the-last-major-release-use-redux-instead-its-really-great https://github.com/acdlite/flummox#40-will-likely-be-the-las...
  - betenoire 11y ago
    the newly recommended library, redux, is great. Flummox was great too, but redux is better, I recommend giving it a shot if you haven't. To the original point, you are still sending the data twice, once in rendered html, and once in that state that gets rehydrated.
    - Ambroos 11y ago
      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/ http://viva.vlaanderen/
      - betenoire 11y ago
        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.

by vkjv 11y ago

jacquesm 11y ago

Speed, simplicity, security.

sergiotapia 11y ago
Synergy.
- cozuya 11y ago
  SEO
  - vkjv 11y ago
    This doesn't make sense. You can still generate all of the HTML with react tags for SEO. The difference, is you can still use React in the client after page load.

dugmartin 11y ago

I played around with building something similar. The problem becomes that you have to send down twice the amount of data for the page - the statically rendered html generated from your data and then the data itself so that when the React components mount their props/state match the statically generated html.

bryanlarsen 11y ago
The easy fix for that is to send the data asynchronously in a separate request. It takes a little longer for the page to go "live", but the static part is functional quicker. A harder fix is to walk the static DOM to inflate your store. It shouldn't be too hard since you can add hints to the DOM to guide your parser.
adregan 11y ago
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). 0: https://facebook.github.io/react/docs/component-specs.html#mounting-componentdidmount https://facebook.github.io/react/docs/component-specs.html#m... 1: http://acdlite.github.io/flummox http://acdlite.github.io/flummox 2: https://github.com/acdlite/flummox#40-will-likely-be-the-last-major-release-use-redux-instead-its-really-great https://github.com/acdlite/flummox#40-will-likely-be-the-las...
- betenoire 11y ago
  the newly recommended library, redux, is great. Flummox was great too, but redux is better, I recommend giving it a shot if you haven't. To the original point, you are still sending the data twice, once in rendered html, and once in that state that gets rehydrated.
  - Ambroos 11y ago
    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/ http://viva.vlaanderen/
    - betenoire 11y ago
      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.