$ npm install react-imported-component
* It's really will never let you down. All credits to your bundler.
π Usage | API | Setup | SSR | CCS Concurrent loading | Webpack/Parcel
Library | Suspense | SSR | Hooks | Library | Non-modules | import(./${value} ) |
babel-macro | webpack only |
---|---|---|---|---|---|---|---|---|
React.lazy | β | β | β | β | β | β | πΉ | |
react-loadable | β | β | β | β | β | β | β | πΏ |
@loadable/component | β | β | β | β | β | β | β | πΏ |
imported-component | β | β | β | β | β | β | β | πΈ |
Read more about what this table displays
Key features:
import
you may provideOther features:
π Better than React.Lazy:
π Better than others:
π Client-side module resolution
main one
, as long as loader code is bundled inside the main chunk, so it should be loaded first.progressive hydration
, and might provide a better UX via feature detection.π¦ Optional bundler integration for the best experience
stat.json
and asset.json
parcel-manifest.json
supportπ―ββοΈWorks better in pair
webpack
integration, the only bundler dependent tool in this list.Just a proper setup and a bit of magic
imported
provides 2 common ways to define a component, which are more different inside than outside
pre-lazy
API.import importedComponent from 'react-imported-component';
const Component = importedComponent( () => import('./Component'));
const Component = importedComponent( () => import('./Component'), {
LoadingComponent: Spinner, // what to display during the loading
ErrorComponent: FatalError // what to display in case of error
});
Component.preload(); // force preload
// render it
<Component... />
lazy
API. It's almost the same React.lazy
outside, and exactly the same inside.import {lazy, LazyBoundary} from 'react-imported-component'
const Component = lazy(() => import('./Component'));
const ClientSideOnly = () => (
<Suspense>
<Component />
</Suspense>
);
// or let's make it SSR friendly
const ServerSideFriendly = () => (
<LazyBoundary> // LazyBoundary is Suspense on the client, and "nothing" on the server
<Component />
</LazyBoundary>
)
LazyBoundary
is a Suspense
on Client Side, and React.Fragment
on Server Side. Don't forget - "dynamic" imports are sync on a server.
Example: React.lazy vs Imported-component
However, you may not load only components - you may load anything
import {useImported} from 'react-imported-component'
const MyCalendarComponent = () => {
const {
imported: moment,
loading
} = useImported(() => import("moment"));
return loading ? "..." : <span>today is {moment(Date.now).format()}</span>
}
// or we could make it a bit more interesting...
const MyCalendarComponent = () => {
const {
imported: format = x => "---", // default value is used while importing library
} = useImported(
() => import("moment"),
moment => x => moment(x).format // masking everything behind
);
return <span>today is {format(Date.now())</span>
}
What you could load using useImported
? Everything - imported
itself is using it to import components.
useImported
is an excellent example for loading translations, which are usually a simple json, in a trackable way.
π‘ did you know that there is another hook based solution to load "something might might need"? The use-sidecar pattern.
π€ Keep in mind - everything here is using useImported
, and you can build whatever you need using just it.
A slim helper to help handle modules
, you might require using useImported
in a component way
import {importedModule, ImportedModule} from 'react-imported-component';
const Moment = importedModule(() => import('moment'));
<Moment fallback="long time ago">
{(momentjs /* default imports are auto-imported*/) => momentjs(date).fromNow()}
</Moment>
Yes, this example was taken from loadable.lib
Can I also use a ref, populated when the library is loaded? No, you cant. Use useImported
for any special case like this.
Plus, there is a Component helper:
<ImportedModule
// import is just a _trackable_ promise - do what ever you want
import={() => import('moment').then(({momentDefault})=> momentDefault(date).fromNow()}
fallback="long time ago"
>
{(fromNow) => fromNow()}
</ImportedModule>
ImportedModule will throw a promise to the nearest Suspense boundary if no
fallback
provided.
If you could not use babel plugin, but do have babel-plugin-macro
(like CRA) - consider using macro API:
import {imported, lazy, useImported} from "react-imported-component/macro";
// notice - there is no default import here
Just importing react-imported-component/macro
would enable babel transformation for the current file.
If you have imported
definition in one file, and use it from another - just import "react-imported-component/macro"
in that another file. See #142
Don't forget - there are TS typings provided.
import {*} from 'react-imported-component';
importedComponent(importFunction, [options]): ComponentLoader
- main API, default export, HOC to create imported component.
importFunction
- function which resolves with Component to be imported.
options
- optional settings
options.async
- activates react suspense support. Will throw a Promise in a Loading State - use it with Suspense in a same way you use React.lazy.
options.LoadingComponent
- component to be shown in Loading state
options.ErrorComponent
- component to be shown in Error state. Will re-throw error if ErrorComponent is not set. Use ErrorBoundary to catch it.
options.onError
- function to consume the error, if one will thrown. Will rethrow a real error if not set.
options.exportPicker
- function to pick not default
export from a importFunction
options.render(Component, state, props)
- function to render the result. Could be used to tune the rendering.
[static] .preload
- static method to preload components.
lazy(importFunction)
- helper to mimic React.lazy behavioruseImported(importFunction, [exportPicker], [options])
- code splitting hook
importFunction
- a function which resolves to default
or wildcard
import(T | {default:T})[exportPicker]
- function to pick "T" from the import[options]
- options to the hook
[options.import]
- controls import. Hooks would be executed only if this is not false[options.track]
- ability to disable server-side usage tracking.useImported
returns complex object(ImportedShape):
imported
- the imported resourceerror
- error (if present)loading
- is it loading right now?loadable
- the underlying Loadable
objectretry
- retry action (in case of error)Hints:
options.import=false
to perform conditional import - importFunction
would not be used if this option set to `false.options.track=true
to perform SSR only import - to usage would be tracked if this option set to `false.There is also API method, unique for imported-component, which could be useful on the client side
addPreloader(fn):fn
- adds a function, result of which would be awaited when any component is loaded. Returns cancel method.import {*} from 'react-imported-component/server';
whenComponentsReady():Promise
- will be resolved, when all components are loaded. Usually on the next "Promise" tick.drainHydrateMarks([stream])
- returns the currently used marks, and clears the list.printDrainHydrateMarks([stream])
- print our the drainHydrateMarks
.createLoadableStream
- creates a steamImportedStream
- wraps another component with import usage tracker.createLoadableTransformer
- creates nodejs StreamTransformergetLoadableTrackerCallback
- helper factory for the stream transformerimport {*} from 'react-imported-component/boot';
whenComponentsReady():Promise
, will be resolved, when all (loading right now) marks are loaded.rehydrateMarks([marks]):Promise
, loads marked async chunks.injectLoadableTracker
- helper factory for the stream transformerAll imports inside library are converted into Loadable
object, and it's often accessible from outside via
useImported().loadable
, useLoadable
(not documented), getLoadable
(not documented). Even if it's documented from TS point of view -
let's keep all fields in a secret, except one:
resolution
- promise reflecting resolution of this loadable objectbabel
pluginyarn imported-components src src/imported.js
to extract all your imports into a run time chunk
(aka async-requires).React.lazy
with our lazy
, and React.Suspense
with our LazyBoundary
.printDrainHydrateMarks
to the server code code.rehydrateMarks
to the client codeThere are examples for webpack, parcel, and react-snap. Just follow them.
On the server:
{
"plugins": ["react-imported-component/babel", "babel-plugin-dynamic-import-node"/* might be optional for babel 7*/]
}
On the client:
{
"plugins": ["react-imported-component/babel"]
}
Imported-Component will hook into dynamic imports, providing extra information about files you want to load.
CLI command imported-components [sources ROOT] [targetFile.js]
(use .ts for TypeScript)
"generate-imported-component": "imported-components src src/imported.js"
When you will execute this command - all imports
among your codebase would be found and extracted to a file provided.
This will gave ability to orchestrate code-splitting later.
If you need to search inside more that one top-level directory - just define more command, saving information into more than one target file.
The current implementation will discover and use all
imports
, even // commented ones
π‘ Feel free to .gitignore these autogenerated files
imported
, lazy
or useImported
Without you using API provided nothing would work.
There are two ways to do it - in a single threaded way, and async
import { printDrainHydrateMarks, drainHydrateMarks } from 'react-imported-component';
// this action will "drain" all currently used(by any reason) marks
// AND print a script tag
const html = renderToString(<YourApp />) + printDrainHydrateMarks();
// OR return list of usedmarks, and yet again CLEAR the marks list.
const html = renderToString(<YourApp />) + "<script>const marks="+JSON.stringify(drainHydrateMarks())+"</script>";
import {createLoadableStream} 'react-imported-component';
let importedStream = createLoadableStream();
// ImportedStream is a async rendering "provider"
const stream = renderToStream(
<ImportedStream stream={importedStream}>
<YourApp />
</ImportedStream>
);
// you'd then pipe the stream into the response object until it's done
stream.pipe(res, { end: false });
// and finalize the response with closing HTML
stream.on('end', () =>
// print marks used in the file
res.end(`${printDrainHydrateMarks(importedStream)}</body></html>`),
)
However, the idea is just to use streams
to separate renders
const html = renderToString(<ImportedStream stream={importedStream}><YourApp /></ImportedStream>) + printDrainHydrateMarks(importedStream);
rehydrateMarks
to the client codeBefore rendering your application you have to ensure - all parts are loaded.
rehydrateMarks
will load everything you need, and provide a promise to await.
import { rehydrateMarks } from 'react-imported-component';
// this will trigger all marked imports, and await for competition.
rehydrateMarks().then(() => {
// better
ReactDOM.hydrate(<App />, document.getElementById('main'));
// or
ReactDOM.render(<App />, document.getElementById('main'));
});
rehydrateMarks
accepts a list of marks
from a server side(drainHydrateMarks
), loads all
necessary chunks and then resolves.
All other code splitting libraries are working a bit differently - they amend webpack
building process,
gathering information about how the final chunks are assembled, and injects the real scripts and styles to the server response,
thus all scripts, used to render something on the Server would be loaded in a parallel in on Client.
Literally - they are defined in the HTML.
React-imported-component
is different, it starts "working" when the bundle is loaded, thus
the loading of chunks is deferred.
π‘ In the normals conditions
react-imported-component
would be "slower" than a "webpack" library. Refer to bundle integration section.
However, it is not a problem, as long as (for now), script execution is single threaded, and even you if can load multiple scripts simultaneously - you can't run them in parallel*.
And there a way to utilize this limitation - just change your entry point, .
And let's call it - a Scheduler optimization. See loading prediction section for more details.
boot
and main
partsrehydrate
at the boot // index.js (boot)
import './src/imported'; // the file generated by "generate-imported-component" (.2)
import {rehydrateMarks} from 'react-imported-component/boot';
rehydrateMarks(); // just start loading what's needed
// load/execute the rest after letting the browser kick off chunk loading
// for example wrapping it in two Promises (1ms timeout or setImmediate)
Promise.resolve().then(() =>
Promise.resolve().then(() => {
// load the rest
require('./main'); // <--- your main scripts
// ! and don't forget to `await rehydrateMarks()` before render
})
);
// main.js
rehydrateMarks().then(() => {
ReactDOM.hydrate(<App />, document.getElementById('root'));
});
This will just start loading extra chunks before the main bundle got completely parsed and executed.
π‘ Another perfect option would be to wait till DomReady event.
// index.js (boot)
import './src/imported'; // the file generated by "generate-imported-component" (.2)
import {rehydrateMarks} from 'react-imported-component/boot';
rehydrateMarks(); // just start loading what's needed
const startApp = () => require('./main'); // <--- your main scripts
// it's "not safe" to start you application before DOM is "ready"
if (document.readyState === "loading") {
document.addEventListener("DOMContentLoaded", startApp);
} else {
startApp();
};
See examples/SSR/parcel-react-ssr/server-stream for details
head
, using async script tag. Not defer! We have to do it asyncloadableTracker
at server sideimport {createLoadableTransformer, getLoadableTrackerCallback} from 'react-imported-component/server';
const importedTracker = createLoadableTransformer(
loadableStream, // stream to observe
getLoadableTrackerCallback() // helper factory to create global tracker.
);
// pipe result of `renderToStream` throught it
const reactRenderStream = ReactDOM.renderToNodeStream(...).pipe(importedTracker);
loadableTracker
at client side // index.js
import './src/imported'; // the file generated by "generate-imported-component" (.2)
import {injectLoadableTracker} from 'react-imported-component/boot';
injectLoadableTracker();
// load the rest after letting the browser kick off chunk loading
// for example wrapping it in two Promises (1ms timeout or setImmediate)
Promise.resolve().then(() =>
Promise.resolve().then(() => {
require('./main')
})
);
This "hack", will first introduce all possible imports
to the imported-component
, then gave it a "tick"
to start loading required once, and only then execute the rest of the bundle.
While the rest(99%) of the bundle would make CPU busy - chunks would be loaded over the network.
π‘This is utilizing the differences between
parse
(unenviable) phase of script, and execute(more expensive) one.
Just wrap "partial hydrated" component with another ImportedStream
so everything needed for it would be not automatically loaded with the main stream.
This library could support hybrid rendering (aka pre-rendering) compatible in two cases:
state hydration
, like getState
in react-snap. See our example.react-snap
example, just dump state
using setTimeout
.react-prerendered-component
to maintain a component state until async chunk is not loaded. See example below.You might not need to wait for all the chunks to be loaded before you can render you app - just use react-prerendered-component.
import imported from 'react-imported-component';
import {PrerenderedComponent} from "react-prerendered-component";
const AsyncComponent = imported(() => import('./myComponent.js'));
<PrerenderedComponent
// component will "go live" when chunk loading would be done
live={AsyncComponent.preload()}
>
// until component is not "live" prerendered HTML code would be used
// that's why you need to `preload`
<AsyncComponent/>
</PrerenderedComponent>
React-prerendered-component
is another way to work with code splitting, which makes everything far better.
There is no build in timeouts to display Error or Loading states. You could control everything by yourself
Suspense
:P.You may use component api if you need it by any reason.
import {ComponentLoader} from 'react-imported-component';
const MyPage = () => (
<ComponentLoader
loadable={() => import('./Page.js')}
// all fields are optional, and matches the same field of importedComponent.
LoadingComponent={Loading}
ErrorComponent={Error}
onError
exportPicker
render
async
/>
);
Out-of-the-box. Literally. CSS-in-JS library, like styled-component
will do it by themselves, and there is nothing
to be managed by this library.
imported
could knew only about JS you've used, not the CSS that js've used...
This library does not support CSS as CSS, as long it's bundler independent and such deep integration is not possible.
Even if deep bundler integration is next following this section - the recomended solution is to skip css
part of it, and use
a more bundler independent way to support CSS:
classNames
(just remove style-loader
from webpack configuration)used-styles
to inject used css files to the resulting HTML.In short (streamed example is NOT short)
const lookup = discoverProjectStyles('./dist');
// ....
const markup = ReactDOM.renderToString(<App />)
const usedStylesAsCSSFiles = getUsedStyles(markup, lookup);
// generate `link` (better rel='preload') to load CSS files
const usedStylesAsStyles = getCriticalStyles(markup, lookup);
// extract critical CSS and inline in to the server response
If you need stream render example with reduced TTFB - please refer to used-styles documentation, or our parcel-bundler stream server example.
With the critical style extracting you might not need the "real" and "full" styles on the page load -
only js
is really required for hydration.
Thus - you might skip loading styles for the initial render, however still need them for the next render.
However - your bundler might think that you have loaded them, this is not true.
To handle this case you need addPreloader
method
// load initial bundle
// await dom ready
// -> HYDRATE APP <-
// add preloader
import {addPreloader} from 'react-imported-component/boot';
addPreloader(() => {
// check that styles are loaded
// or return Promise if they are not
});
// any not yet loaded ImportedComponent
// will await for it's own `import` as well as for
// promise returned from preloaders
See critical css example for details
Use react-imported-component/macro
for CRA compatible SSR code splitting without ejecting.
It is safe to always use
react-imported-component/macro
withoutbabel-plugin-macros
, BUT withreact-hot-loader/babel
enabled, as long as it will remove allmacros
.
Keep in mind - you dont "need" this. It will just make integration slightly better in terms of prefetching (which affects network recourse priority) and thus startup time.
You might preload/prefetch used styles and scripts, which were defined with webpackChunkName
// get mark somehow (drainHydrateMarks(importedStream))
import {getMarkedChunks} from 'react-imported-component/server';
const chunkNames = getMarkedChunks(marks);
webpack-imported - provides webpack
plugin to get data from the build, as well as to use it.
Supports prefetching and critical style guidance.
import {WebpackImport} from "webpack-imported/react";
import importedStat from "build/imported.json";
<WebpackImport stats={importedStat} chunks={getMarkedChunks(drainHydrateMarks())} />
If you do have only stat.json
- it could be converted into "importedStat" by webpack-imported
without adding plugin.
Alternatively - you can discover all resources you have to preload using flush-webpack-chunks
const { js, styles } = flushChunks(webpackStats, {
chunkNames,
});
const prefetch = (targets, as) => (
targets
.map(url => `<link as="${as}" rel="preload" href="${url}" />`)
.join('')
);
res.send(prefetch(scripts, "script"));
res.send(prefetch(stylesheets, "style"));
DO NOT actually load reported resources - only preload them, and let webpack do rest.
You you are using assets-webpack-plugin then you have only list of assets, without dependencies between. That's enought.
const prefetchChunks = (chunks, assets) => (
chunks
.map(chunk => [
assets[chunk].js && `<link rel="preload" as="script" href="${assets[chunk].js}" />`,
assets[chunk].css && `<link rel="preload" as="style" href="${assets[chunk].css}" />`,
].join('')
).join('')
);
res.send(prefetchChunks(chunkNames, assets));
Use parcel-manifest
and getMarkedFileNames
(instead of getMarkedChunks
) to find which files were required and has to be imported.
Keep in mind - the base path would be different and you have to resolve
the right files in to the right files (/app/index
to index.js
).
Consider using concurrent-loading technique only.
react-imported-component
is compatible with react-snap out of the box.
Works even better with react-prerendered-component
.
react-imported-component
is compatible with webpack-external-import,
as long as it executes imports
, thus executes custom logic
useImported
and Suspense
useImported
is not supposed to be used with Suspense (by design), while it could
const MyComponent = () => {
const {loading, error, loadable, imported} = useImported(() => import("..."));
if (loading) throw loadable.resolution; // throw to the nearest Suspense boundary
if (error) throw error; // throw to the nearest Error boundary
// do something with `imported` value
}
It was usually a headache - async components and SSR, which is currently sync. React-imported-component break this cycle, making ServerSide rendering sync, and providing comprehensive ways to rehydrate rendered tree on client. It will detect server-side environment and precache all used components.
On the server side imported
would auto-import any found import. As long as not all imports could be executed at Server Side you might
pop out this feature using a "magic comment".
import(/* client-side */ './file');
Or file filtering
import {setConfiguration} from 'react-imported-component';
setConfiguration({
fileFilter: (fileName) => file.indexOf('/client')!==0
});
It does not matter how do you bundle your application - it could be even browser. The secrect sause is a cli command, to extract all your imports into imports map, and use it later to load chunks by request.
In case of imported component SSR is a "dry run" of your application - an easy way to discover required pieces powered by zero latency(you are already on the server) and super fast speed connection (all scripts are in memory).
However - you dont need SSR to get the same benefits on pure ClientSideRendered solutions - prediction would be enought. The common approach is to
This causes effect known as loading waves
, the effect SSR could mitigate almost in full.
However, nothing stops you from loading translation data in the parallel to the routes, and loading route and sub route in the same time, not sequentially. You can have backend-for-frontend, why not to have frontend-for-frontend? Just handle route, cookies, and whatever you could handle, outside of React. Redux-first-router and principles behind it are the great example of this idealogy.
There is design limitation with React.lazy support from RHL size, so they could not be reloaded without
state loss if lazy
is created not in the user space. At it would be created inside imported.
If React-Hot-Loader is detected lazy
switches to imported async
mode, this behaves absolutely the same.
Library
- the library nameSuspense
- does it support Suspense featureSSR
- does it support SSRHooks
- does it have hooks APILibrary
- does it support library, not Component level splittingNon-modules
- could it "import" generic promise, not a real dynamic module importimport('./${value}')
- does it support a full dynamic import - ability to import any file.babel macro
- ability to work with babel-plugin-macroswebpack only
- is this solution hard bould to webpackAnother loaders exists, and the only difference is in API, and how they manage (or not manage) SSR.
(no SSR) React.Lazy
(webpack only) With react-loadable
(not compatible with hooks) react-async-component
(webpack only) loadable-components
(webpack only) react-universal-component
(not a component loader) use-sidecar
MIT
© 2010 - cnpmjs.org x YWFE | Home | YWFE