mirror of
https://github.com/hanzoai/next.js.git
synced 2026-10-30 14:46:38 +00:00
Niklas MischkulnigandGitHub
d3529bad5d
- Before, there was a separate AST traversal that collected `next-dynamic` imports - Now, we use transitions (which are inserted by the existing next-custom-transform) to tell Turbopack about the next-dynamic imports - Unlike Webpack (where the react-loadable identifiers are `path/to/parent-module -> ./imported-client`), Turbopack just uses the module id: `[project]/path/to/imported-client.js [app-client] (ecmascript, next/dynamic entry)` - the `next-dynamic` transition only inserts the marker module (i.e. for the SSR `import()`) - the `next-dynamic-client` transition inserts the marker module and changes the module context (used to get the client module name) - Now, we use the correct `AvailabilityInfo` for the next/dynamic chunks to preload, and they are not explicitly emitted. If they are for some reason not the same chunks that are actually emitted for the dynamic import, you get a hard error. (Previously, they didn't use the same `AvailabilityInfo` as the real async chunks, so they usually bundled another copy of React, and also had a different chunk name hash) - For Turbopack, react-loadable manifests are now scoped per page instead of globally
15 lines
292 B
JavaScript
15 lines
292 B
JavaScript
import dynamic from 'next/dynamic'
|
|
const DynamicComponent1 = dynamic(
|
|
() => handleImport(import('./components/hello1')),
|
|
{
|
|
loading: () => null,
|
|
ssr: false,
|
|
}
|
|
)
|
|
|
|
const DynamicComponent2 = dynamic(() =>
|
|
import('./components/hello2').then((mod) => {
|
|
return mod.Button
|
|
})
|
|
)
|