|
| 1 | +# Code Splitting |
| 2 | + |
| 3 | +What is code splitting? From the webpack documentation: |
| 4 | + |
| 5 | +> For big web apps it’s not efficient to put all code into a single file, especially if some blocks of code are only required under some circumstances. Webpack has a feature to split your codebase into “chunks” which are loaded on demand. Some other bundlers call them “layers”, “rollups”, or “fragments”. This feature is called “code splitting”. |
| 6 | +
|
| 7 | +## Server Rendering and Code Splitting |
| 8 | + |
| 9 | +Let's say you're requesting a page that needs to fetch a code chunk from the server before it's able to render. If you do all your rendering on the client side, you don't have to do anything special. However, if the page is rendered on the server, you'll find that React will spit out the following error: |
| 10 | + |
| 11 | +> Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server: |
| 12 | +
|
| 13 | +> (client) <!-- react-empty: 1 - |
| 14 | +
|
| 15 | +> (server) <div data-reactroot=" |
| 16 | +<!--This comment is here because the comment beginning on line 13 messes up Sublime's markdown parsing--> |
| 17 | +
|
| 18 | +Different markup is generated on the client than on the server. Why does this happen? When you register a component or generator function with `ReactOnRails.register`, react on rails will render the component as soon as the page loads. However, react-router renders a comment while waiting for the code chunk to be fetched from the server. This means that react will tear all of the server rendered code out of the DOM, and then rerender it a moment later once the code chunk arrives from the server, defeating most of the purpose of server rendering. |
| 19 | + |
| 20 | +### The solution |
| 21 | + |
| 22 | +To prevent this, you have to wait until the code chunk is fetched before doing the initial render on the client side. To accomplish this, react on rails allows you to register a renderer. This works just like registering a generator function, except that the function you pass takes three arguments: `renderer(props, railsContext, domNodeId)`, and is responsible for calling `ReactDOM.render` to render the component to the DOM. React on rails will automatically detect when a generator function takes three arguments, and will not call `ReactDOM.render`, instead allowing you to control the initial render yourself. |
| 23 | + |
| 24 | +Here's an example of how you might use this in practice: |
| 25 | + |
| 26 | +#### page.html.erb |
| 27 | +```erb |
| 28 | +<%= react_component("NavigationApp", prerender: true) %> |
| 29 | +<%= react_component("RouterApp", prerender: true) %> |
| 30 | +<%= redux_store_hydration_data %> |
| 31 | +``` |
| 32 | + |
| 33 | +#### clientRegistration.js |
| 34 | +```js |
| 35 | +import ReactOnRails from 'react-on-rails'; |
| 36 | +import NavigationApp from './NavigationApp'; |
| 37 | + |
| 38 | +// Note that we're importing a different RouterApp that in serverRegistration.js |
| 39 | +// Renderer functions should not be used on the server, because there is no DOM. |
| 40 | +import RouterApp from './RouterAppRenderer'; |
| 41 | +import applicationStore from '../store/applicationStore'; |
| 42 | + |
| 43 | +ReactOnRails.registerStore({applicationStore}); |
| 44 | +ReactOnRails.register({ |
| 45 | + NavigationApp, |
| 46 | + RouterApp, |
| 47 | +}); |
| 48 | +``` |
| 49 | + |
| 50 | +#### serverRegistration.js |
| 51 | +```js |
| 52 | +import ReactOnRails from 'react-on-rails'; |
| 53 | +import NavigationApp from './NavigationApp'; |
| 54 | + |
| 55 | +// Note that we're importing a different RouterApp that in clientRegistration.js |
| 56 | +import RouterApp from './RouterAppServer'; |
| 57 | +import applicationStore from '../store/applicationStore'; |
| 58 | + |
| 59 | +ReactOnRails.registerStore({applicationStore}); |
| 60 | +ReactOnRails.register({ |
| 61 | + NavigationApp, |
| 62 | + RouterApp, |
| 63 | +}); |
| 64 | +``` |
| 65 | +Note that you should not register a renderer on the server, since there won't be a domNodeId when we're server rendering. Note that the `RouterApp` imported by `serverRegistration.js` is from a different file. For an example of how to set up an app for server rendering, see the [react router docs](react-router.md). |
| 66 | + |
| 67 | +#### RouterAppRenderer.jsx |
| 68 | +```jsx |
| 69 | +import ReactOnRails from 'react-on-rails'; |
| 70 | +import React from 'react'; |
| 71 | +import ReactDOM from 'react-dom'; |
| 72 | +import Router from 'react-router/lib/Router'; |
| 73 | +import match from 'react-router/lib/match'; |
| 74 | +import browserHistory from 'react-router/lib/browserHistory'; |
| 75 | +import { Provider } from 'react-redux'; |
| 76 | + |
| 77 | +import routes from '../routes/routes'; |
| 78 | + |
| 79 | + |
| 80 | +const RouterAppRenderer = (props, railsContext, domNodeId) => { |
| 81 | + const store = ReactOnRails.getStore('applicationStore'); |
| 82 | + const history = browserHistory; |
| 83 | + |
| 84 | + match({ history, routes }, (error, redirectionLocation, renderProps) => { |
| 85 | + if (error) { |
| 86 | + throw error; |
| 87 | + } |
| 88 | + |
| 89 | + const reactElement = ( |
| 90 | + <Provider store={store}> |
| 91 | + <Router {...renderProps} /> |
| 92 | + </Provider> |
| 93 | + ); |
| 94 | + |
| 95 | + ReactDOM.render(reactElement, document.getElementById(domNodeId)); |
| 96 | + }); |
| 97 | +}; |
| 98 | + |
| 99 | +export default RouterAppRenderer; |
| 100 | +``` |
| 101 | + |
| 102 | +What's going on in this example is that we're putting the rendering code in the callback passed to `match`. The effect is that the client render doesn't happen until the code chunk gets fetched from the server, preventing the client/server checksum mismatch. |
| 103 | + |
| 104 | +The idea is that match from react-router is async; it fetches the component using the getComponent method that you provide with the route definition, and then passes the props to the callback that are needed to do the complete render. Then we do the first render inside of the callback, so that the first render is the same as the server render. |
| 105 | + |
| 106 | +The server render matches the deferred render because the server bundle is a single file, and so it doesn't need to wait for anything to be fetched. |
| 107 | + |
| 108 | +### Working Example |
| 109 | + |
| 110 | +There's an implemented example of code splitting in the `spec/dummy` folder of this repository. |
| 111 | + |
| 112 | +See: |
| 113 | + |
| 114 | +- [spec/dummy/client/app/startup/clientRegistration.jsx](../../spec/dummy/client/app/startup/clientRegistration.jsx) |
| 115 | +- [spec/dummy/client/app/startup/serverRegistration.jsx](../../spec/dummy/client/app/startup/serverRegistration.jsx) |
| 116 | +- [spec/dummy/client/app/startup/DeferredRenderAppRenderer.jsx](../../spec/dummy/client/app/startup/DeferredRenderAppRenderer.jsx) <-- Code splitting implemented here |
| 117 | +- [spec/dummy/client/app/startup/DeferredRenderAppServer.jsx](../../spec/dummy/client/app/startup/DeferredRenderAppServer.jsx) |
| 118 | +- [spec/dummy/client/app/components/DeferredRender.jsx](../../spec/dummy/client/app/components/DeferredRender.jsx) |
| 119 | +- [spec/dummy/client/app/components/DeferredRenderAsyncPage.jsx](../../spec/dummy/client/app/components/DeferredRenderAsyncPage.jsx) |
| 120 | + |
| 121 | +### Caveats |
| 122 | + |
| 123 | +If you're going to try to do code splitting with server rendered routes, you'll probably need to use seperate route definitions for client and server to prevent code splitting from happening for the server bundle. The server bundle should be one file containing all the JavaScript code. This will require you to have seperate webpack configurations for client and server. |
| 124 | + |
| 125 | +The reason is we do server rendering with ExecJS, which is not capable of doing anything asynchronous. It would be impossible to asyncronously fetch a code chunk while server rendering. See [this issue](https://github.com/shakacode/react_on_rails/issues/477) for a discussion. |
| 126 | + |
| 127 | +Also, do not attempt to register a renderer on the server. Instead, register either a generator function or a component. If you register a renderer in the server bundle, you'll get an error when react on rails tries to server render the component. |
| 128 | + |
| 129 | +## How does Webpack know where to find my code chunks? |
| 130 | + |
| 131 | +Add the following to the output key of your webpack config: |
| 132 | + |
| 133 | +```js |
| 134 | +config = { |
| 135 | + output: { |
| 136 | + publicPath: '/assets/', |
| 137 | + } |
| 138 | +}; |
| 139 | +``` |
| 140 | + |
| 141 | +This causes Webpack to prepend the code chunk filename with `/assets/` in the request url. The react on rails sets up the webpack config to put webpack bundles in `app/assets/javascripts/webpack`, and modifies `config/initializers/assets.rb` so that rails detects the bundles. This means that when we prepend the request url with `/assets/`, rails will know what webpack is asking for. |
| 142 | + |
| 143 | +See [rails-assets.md](./rails-assets.md) to learn more about static assets. |
| 144 | + |
| 145 | +If you forget to set the public path, webpack will request the code chunk at `/{filename}`. This will cause the request to be handled by the Rails router, which will send back a 404 response, assuming that you don't have a catch-all route. In your javascript console, you'll get the following error: |
| 146 | + |
| 147 | +> GET http://localhost:3000/1.1-bundle.js |
| 148 | +
|
| 149 | +You'll also see the following in your Rails development log: |
| 150 | + |
| 151 | +> Started GET "/1.1-bundle.js" for 127.0.0.1 at 2016-11-29 15:21:55 -0800 |
| 152 | +> |
| 153 | +> ActionController::RoutingError (No route matches [GET] "/1.1-bundle.js") |
| 154 | +
|
| 155 | +It's worth mentioning that in Webpack v2, it's possible to register an error handler by calling `catch` on the promise returned by `System.import`, so if you want to do error handling, you should use v2. The [example](#working-example) in `spec/dummy` is currently using Webpack v1. |
0 commit comments