Flush Chunks Boilerplate (Webpack)
It's specifically for when you're using Webpack with React Universal Component's
flushModuleIds() and Webpack Flush Chunks's
git clone https://github.com/faceyspacey/flush-chunks-boilerplate-webpack.git cd flush-chunks-boilerplate-webpack yarn
Note: after this point, the readmes are the same for all
yarn start yarn run start:prod
After selecting one of the above commands, open localhost:3000 in your browser. View the source in the browser to see what chunks are being sent.
Things To Do
try both commands and examine their corresponding Webpack configs and the corresponding server file:
view the source in your browser to see what the server sends (do this often)
trueand then view the source in your browser to see when corresponding chunks are sent vs. not sent.
open the browser console Network tab and see when in fact the
Example.jschunk is asynchronously loaded (it won't be if
state.showstarts off as
true, which is desired result, i.e. because the client synchronously renders exactly what was rendered on the server)
<Example />components to see that HMR works--even for split chunks. Do so with both
state.showpre-set to both
trueto verify HMR works in all scenarios. There's warning that may occur on your first edit. Don't worry about it. The change will work and be reflected instantly. It's basically a matter of supression within the
edit and save the CSS files to confirm HMR works for CSS as well, thanks to extract-css-chunks-webpack-plugin
when bundling for production, examine the build folder (or,
buildServerfolders when using the Webpack boilerplates) to see exactly what chunks and files are built for you. Notice the
.jsand one ending with
server/render.jsand follow the directions of what lines to comment and uncomment to test rendering your chunks as strings vs. React components.
server/render.jsand from the return of
styleswhile running in production to see your CSS embedded directly in the response page. View the source in your browser to confirm. Note: during development, external stylesheets will still be used for HMR to work; this is automatic.
check out the amazing package, webpack-hot-server-middleware, to see how dual-compilation works for both your server and client bundles. It's very fast because it shares compiled files between the 2 bundles. We've been surprised this hasn't been more popular and the defacto solution for rendering both bundles. It's very solid. We think you will like it...Another thing nice about it is how seamlessly it ushers your compilation stats to the render function you pass to express's
If you're not embedding CSS directly in your response strings, you can forget about ushering the
outputPath to your
serverRender function. Keep in mind though that if you do, and if you render the server with Webpack this can become a time-sink to figure out for those not familiar with how Webpack mocks the file system. Basically by default the file system won't be what you expect it to be if you call
path.resolve(__dirname, '..') within a webpack-compiled portion of your code, which is why it's very nice how webpack-hot-server-middleware allows you to pass options from Babel code where you can get your bundle's output path resolved properly. Universal Webpack is awesome, but has a few hurdles to doing correctly, particularly in development. webpack-hot-server-middleware solves those hurdles.
Hopefully insights from this boilerplate simplifies things for you. The key is to recognize the boundary this boilerplate has chosen between what server code is compiled by Webpack and what code is compiled by Babel. The boundary specifically is
server/index.webpack.js, which is handled by Babel and
server/render.js, which is handled by Webpack--both of which are run on the server.
If you haven't rendered your server with Webpack before, now's a good time to give the Webpack boilerplates a try. Helping make that--along with complete HMR--more of a mainstream thing is a side aim of these repos.
Final Note: Hot Module Replacement
this basically applies to the universal webpack boilerplates
You will notice that the server code is watched with
package.json. The goal is obviously HMR everywhere, since no matter what some of your code is built outside of Webpack.
There is one gotcha with that though: if you edit the server code (not compiled by Webpack), it will update, but then connection to the client will be lost, and you need to do a refresh. This is very useful for cases where you are actively refreshing, such as when you're checking the output from you server in your browser source code tab, but obviously not the pinnacle in universal HMR.
However, when your not editing your
express code much, and if you're editing webpack-compiled code (whether rendered on the client or server), HMR will isomorphically work with no unexpected hiccups; and that awesomeness is likely what you'll experience most of the time. That's one of the key benefits of webpack-hot-server-middleware.
If you have a solution to reconnecting the client to HMR after
babel-watch reloads the server code, we'd love to hear it.
Long live the dreams of Universal HMR and Universal Code-Splitting!
We use commitizen, so run
npm run cm to make commits. A command-line form will appear, requiring you answer a few questions to automatically produce a nicely formatted commit.