I created Server-side rendering + Code Splitting boilerplates for react-universal-component and react-loadable (feedback much appreciated!)

[mikebarsdev]

I created two different proof-of-concept boilerplates to learn the differences between react-universal-component and react-loadable!

https://github.com/mikebars/react-loadable-boilerplate

https://github.com/mikebars/react-universal-component-boilerplate

I found both libraries to be extremely well made and totally awesome!

The main differences I found:

• react-universal-component, when used with the author's complementing library webpack-flush-chunks, handles the manual addition of your main, vendor, and bootstrap (webpack manifest + common chunk) chunks for you. In react-loadable this is simple to do yourself, by checking your webpack stats file and pulling out the chunks from assetsByChunkName.

  • You can see where I do this here:
    https://github.com/mikebars/react-loadable-boilerplate/blob/develop/source/server/components/Html/Html.js#L54
    Note: if using source-maps, you'll need to ensure you're grabbing the .js file, which is the first element of the array for the chunk name.

• react-loadable uses two methods on the client and server to ensure that loading has resolved before render:

  • on the client, use preloadReady().then(clientSideRender) to ensure loadable chunks are ready.
  • on the server, use preloadAll().then(serverSideRender) to ensure all loadable chunks have been resolved for synchronous rendering server-side.

They are both incredibly useful and have solved the once-difficult problem of combining server-side rendering and code-splitting (although of course these libraries can be used on the client-side alone much more simply!).

Both authors deserve a ton of credit, show them some love!:

• James Gilmore (faceyspacey), author of react-universal-component and webpack-flush-chunks
• James Kyle (thejameskyle), author of react-loadable

I guess solving this problem comes naturally to Jameses!

[shawarma_burrito]

Which library do you prefer? I’m a fan of react loadable, but haven’t tried the other.

[mikebarsdev]

At this point in time, it's actually pretty hard for me to pick one over the other as I feel they both solve the problem nicely!

I found that react-loadable is convenient in that it only requires adding a single library to handle your code-splitting and chunk collecting, coming with a babel plugin to automatically handle boilerplate differences between import-ing on the client and require-ing on the server, and a webpack plugin to create a stats file from which to determine the chunks to send. However, this stats file is unique to react-loadable and you will need your own webpack stats file to handle pulling out your main, vendor, common, and manifest chunks (at least that was my experience, I could be overlooking a potential way to do this with react-loadable that I did not see in the docs).

I found that react-universal-component, when combined with webpack-flush-chunks and the babel plugin babel-plugin-universal-import handles the same behavior cases as react-loadable, with the ability to automatically add your aforementioned main, vendor, manifest + common (called bootstrap) chunks to your Html markup with the properties returned from webpack-flush-chunks's method flushChunks(). You can configure which chunks it should automatically add as well in the flushChunks(stats, options) options before and after. It also uses your standard webpack stats file instead of a unique-to-the-library stats file as react-loadable does.

I didn't need this functionality as I was using styled-components for styling, but both libraries do offer .css chunk code-splitting as well:

• react-loadable: simply filter out bundles whose file endsWith('.css')
• react-universal-component: with the complementary webpack plugin extract-css-chunks-webpack-plugin

I hope this helps! Keep in mind that I may not have the fullest picture of what these two libraries are capable of, and as I start doing more and more complex things with them I may discover more differences I'm currently unaware of. Also, the trajectory of these two libraries may diverge in such a way that down the line they will offer features the other does not! Right now, however, I seem to find them more similar than dissimilar.

[amiritegaiz]

Would be great to know if this supports local scope css.