Title may sound dumb, but I can't use variables w/ the dynamic variables.
const t = './page'
dynamic(import(t))
Fails but dynamic(import('./page')) works.
That's fine I guess - I'm currently circumventing this by having all of my templates in an array and using some logic to figure out which template to use by its key value.
However, it looks like I could maybe do this with the modules{} object that dynamic takes. Would it be more performant or would it ultimately be the same thing?
Please have a look at these lessons: https://learnnextjs.com/excel/lazy-loading-modules
You can't use variables in dynamic imports.
But you can conditionally load multiple components here.
Check this API: https://github.com/zeit/next.js#4-with-multiple-modules-at-once
Why can't you use variables in dynamic imports? Seems like it kind of defeats the purpose
@tweeres04 the purpose of dynamic imports is to dynamically load modules only when they are required, that allow to reduce the size of the bundle, e.g. only load admin related modules and components if the user is an admin user.
The TC39 proposal mentions passing a variable or template string literals in order to not only lazy load, but also pick which module to load at runtime based on some context. An example from the proposal is import(`./language-packs/${navigator.language}.js\`)
Will this ever be supported by next.js? I am hoping to achieve something like dynamic(import('./blog/${post-slug}`)), saving each of my blog posts as react components.
Either way, the documentation suggests the tc39 import spec is supported, which it only partially supports. I think some clarification on that would clear things up for some.
The TC39 proposal mentions passing a variable or template string literals in order to not only lazy load
I'd love to hear some clarification as well if possible. @arunoda?
More info: Webpack should make this possible according to this article: https://dev.to/kayis/dynamic-imports-with-webpack-2 (I couldn't find anything in Webpack's own documentation) but it doesn't seem to work with Next's config for some reason
Ok, after doing more research it seems that Webpack itself only allows for string literals or template string literals (i.e. backtick strings). If a template string is provided then Webpack will bundle together all files that could possibly match the template into one chunk.
Also, after reading the TC39 proposal more carefully it seems like "import() accepts arbitrary strings" which I'm interpreting as: either a string literal or a string template (variables are not allowed).
I still don't know what's the best way to import a single module dynamically given a runtime-determined name.
No official statements on this yet?
Maybe this could be achieved by providing a set of available options to the dynamic require somehow. There is no way to support any value for the dynamic import, as webpack need to know what bundles to prepare in advance. I'd be surprised if this was possible in a feasible way.
I tried doing something like
dynamic(import(`./blog/${postSlug}`))
as mentioned by @tweeres04, with Next 7. It does load the component but SSR doesn't work (it shows "loading..."). Is this behavior expected? @arunoda
It is not expected, but indicates you're probably doing something non-standard, can you provide a minimal reproduction in a new issue? Following the issue template.
@timneutkens thanks! I ended up going with what you suggested here: https://github.com/zeit/next.js/issues/5208#issuecomment-423110547 - I'll create a minimal repro when I have time / run into this again.
Most helpful comment
The TC39 proposal mentions passing a variable or template string literals in order to not only lazy load, but also pick which module to load at runtime based on some context. An example from the proposal is
import(`./language-packs/${navigator.language}.js\`)Will this ever be supported by next.js? I am hoping to achieve something like
dynamic(import('./blog/${post-slug}`)), saving each of my blog posts as react components.Either way, the documentation suggests the tc39 import spec is supported, which it only partially supports. I think some clarification on that would clear things up for some.