Gathering detailed insights and metrics for gatsby-plugin-loadable-components-ssr
Gathering detailed insights and metrics for gatsby-plugin-loadable-components-ssr
Gathering detailed insights and metrics for gatsby-plugin-loadable-components-ssr
Gathering detailed insights and metrics for gatsby-plugin-loadable-components-ssr
Gatsby plugin for using @loadable/component with Gatsby's SSR
npm install gatsby-plugin-loadable-components-ssr
Typescript
Module System
Min. Node Version
Node Version
NPM Version
Updated dependencies
Updated on May 15, 2020
Renamed option renderFn to useHydrate
Updated on Mar 03, 2020
Added option to specify render function
Updated on Mar 03, 2020
Fixed error logged on console on develop
Updated on Mar 03, 2020
Fixed a bug that rendered all chunks on all the pages
Updated on Dec 18, 2019
v1.0.6
Updated on Dec 15, 2019
JavaScript (98.39%)
Shell (1.61%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
49 Stars
96 Commits
25 Forks
4 Watchers
26 Branches
14 Contributors
Updated on Jul 03, 2023
Latest Version
4.3.2
Package Id
gatsby-plugin-loadable-components-ssr@4.3.2
Unpacked Size
11.34 kB
Size
4.30 kB
File Count
13
NPM Version
8.12.1
Node Version
18.4.0
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
3
Server-side rendering loadable components in your gatsby application.
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
As described in the documentation 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.
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.
Simply add gatsby-plugin-loadable-components-ssr
to the plugins array in gatsby-config.js
.
1// gatsby-config.js 2 3module.exports = { 4 plugins: [ 5 "gatsby-plugin-loadable-components-ssr", 6 // OR 7 { 8 resolve: `gatsby-plugin-loadable-components-ssr`, 9 options: { 10 // Whether replaceHydrateFunction should call ReactDOM.hydrate or ReactDOM.render 11 // Defaults to ReactDOM.render on develop and ReactDOM.hydrate on build 12 useHydrate: true, 13 }, 14 }, 15 ], 16}
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.
1 { 2 resolve: "gatsby-plugin-loadable-components-ssr", 3 options: { 4 preloadTags: false 5 }, 6 }
Loadable does not seem to be planning support for React 18 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.
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):
1// gatsby-browser.js 2 3exports.replaceHydrateFunction = () => { 4 return (element, container, callback) => { 5 ReactDOM.render(element, container, callback) 6 } 7}
After:
1// gatsby-browser.js 2 3const loadableReady = require("@loadable/component").loadableReady 4 5exports.replaceHydrateFunction = () => { 6 return (element, container, callback) => { 7 loadableReady(() => { 8 ReactDOM.render(element, container, callback) 9 }) 10 } 11}
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. 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.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
no dangerous workflow patterns detected
Reason
dependency not pinned by hash detected -- score normalized to 3
Details
Reason
Found 4/21 approved changesets -- score normalized to 1
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
license file not detected
Details
Reason
project is not fuzzed
Details
Reason
security policy file not detected
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
54 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More