gatsby-plugin-loadable-components-ssr
Version:
Server-side rendering loadable components in your gatsby application
98 lines (69 loc) • 4.01 kB
Markdown
## Description
Server-side rendering [loadable components](https://loadable-components.com/) in your gatsby application.
## Installation
`npm install --save gatsby-plugin-loadable-components-ssr @loadable/component`
_Latest version of this plugin for v2 Gatsby is 2.1.0_
_Latest version of this plugin for v3 Gatsby is 3.4.0_
## Problem
As described in [the documentation](https://loadable-components.com/docs/server-side-rendering/) a series of steps
must be followed to implement server-side rendering in your app. However, it's not trivial to apply them to a gatsby application.
## Solution
This plugin implements the steps described in the link above using gatsby's APIs, so you can use it only by adding
`gatsby-plugin-loadable-components-ssr` in your list of gatsby plugins.
## Usage
Simply add `gatsby-plugin-loadable-components-ssr` to the plugins array in `gatsby-config.js`.
```javascript
// gatsby-config.js
module.exports = {
plugins: [
"gatsby-plugin-loadable-components-ssr",
// OR
{
resolve: `gatsby-plugin-loadable-components-ssr`,
options: {
// Whether replaceHydrateFunction should call ReactDOM.hydrate or ReactDOM.render
// Defaults to ReactDOM.render on develop and ReactDOM.hydrate on build
useHydrate: true,
},
},
],
}
```
## Preloading chunks
By default, this plugin will create `preload` tags for the chunks it creates. This *can* cause overeaging fetching and inaccurate prioritizing of fetching of the chunks. You can disable this behavior with the `preloadTags` option. You can then use a more fine-grained approach with `/* webpackPreload: true */` for known above-the-fold components like heros.
```javascript
{
resolve: "gatsby-plugin-loadable-components-ssr",
options: {
preloadTags: false
},
}
```
## React 18 and Gatsby 5 Support
Loadable [does not seem to be planning support for React 18](https://github.com/gregberge/loadable-components/issues/718) and Gatsby v5 will require React 18. React 18 ships with `React.lazy` which performs the same code-splitting + SSR that we are accomplishing here. There are no plans to write compatibility for React 18 / Gatsby 5 with this plugin, so the migration path should be one to `React.lazy`. This should result in an overall simpler implementation, and should be considered a positive that this plugin will no longer be needed.
## My gatsby-browser.js already implements replaceHydrateFunction API
This plugin uses `replaceHydrateFunction` API. If your application also implements this API (`gatsby-browser.js`)
make sure you wrap your implementation with `loadableReady(() => ...)`.
Before (from the example [in here](https://www.gatsbyjs.org/docs/browser-apis/#replaceHydrateFunction)):
```javascript
// gatsby-browser.js
exports.replaceHydrateFunction = () => {
return (element, container, callback) => {
ReactDOM.render(element, container, callback)
}
}
```
After:
```javascript
// gatsby-browser.js
const loadableReady = require("@loadable/component").loadableReady
exports.replaceHydrateFunction = () => {
return (element, container, callback) => {
loadableReady(() => {
ReactDOM.render(element, container, callback)
})
}
}
```
## Note on Fully Dynamic Imports
While loadable does support fully dynamic imports (e.g. `const MyDynamic = loadable(() => import(`/components/${myComponentVar}`))`), the plugin currently loses the relationship between that chunk and the webpack mapping so it 404s. The [workaround is here using a hardcoded 'map' component](https://github.com/graysonhicks/gatsby-plugin-loadable-components-ssr/issues/4#issuecomment-684814893). This works well, but does not scale as well as fully dynamic as the number of components grows. There is not a plan to resolve this, as the hope is to deprecate this library when React 18 gets a stable release and you could use the `React.lazy()` pattern [described here](https://www.youtube.com/watch?v=lypEGNEIRKE).