-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The default shouldPreload logic seems incorrect #3
Comments
I think the engine kind of does this anyways. By preloading statically imported modules we gain a slight advantage over the parser but not much else, still it's not a bad idea. The use case I originally had in mind was lazy-loaded page components. We want them to be downloaded and parsed before the user navigates to them. The problem with that is inferring which modules apply in that case, so I cast a wide net instead. It's a naive implementation, which is why I left What do you think about this:
Where the keywords 'static' and 'dynamic' refer to your default and mine, respectively. There would be no default, the plugin would throw if the user didn't choose. |
Chrome (the only browser to implement As a result, we continue to recommend including
I get the use case, but wouldn't you get the same affect by statically importing them rather than dynamically importing them? And if code splitting is what you want, you could get that via the <script type=module importance=low href="..."> Regardless, though, I do think there's value in being able to use
The hard part in all this (why I think there should be a plugin rather than manually writing your own If the However if What do you think? If you'd prefer to have this plugin not manage generating dependency graphs for entry points, I'd be happy to write a separate plugin that does do that ( |
Let me try to summarize your suggestion, and please let me know if I've covered your concerns: {
// preloads all modules that are included in the graph,
// accd to your code above
preload: 'static',
// everything 'static' does', but includes `import()`s in those modules,
// and all their static dependencies
preload: 'dynamic',
// when true, preload the module.
preload: (x: ChunkInfo) => Boolean
} That sounds really useful to me also, based on your very clear and informative explanation of Chrome team's recommendations above, I'm comfortable making |
Actually, before continuing, I want to confirm some behavior about Rollup. At the moment, it looks like Rollup always lists all imports in the graph for entry chunks, and it looks like this is actually the intended behavior. If this is the case, then adding logic to traverse the graph is not need -- that being said, I'm not sure this is a good feature on Rollup's part, but I need to confirm. Let me get back to you! |
The default
shouldPreload
function in this plugin will preload everything that is a dynamic import or has exports (without being a facade chunk). I'm not sure why that criteria was chosen.Normally you want to preload everything in your initial static module graph, i.e. all the things that the browser would naturally load if given your primary module entry point. The idea is you want to tell the browser ahead of time what's going to be in the graph (so it can make the requests in parallel, without having to discover them).
In some cases you may also want to preload certain modules in the graph of a dynamic entry point (e.g. a router that dynamically loads all routes), but most of the time the reason they're in a dynamic entry point is they're conditionally loaded, so preloading them would defeat the purpose of conditionally loading them.
I think the default logic to determine the list of modules to preload should be:
Every chunk that's in the module graph of all static entry points.
Then, optionally, a developer may choose to specify dynamic entry chunks whose graph they also want to preload.
Lastly, I could see a use case for never preloading certain modules, so it probably makes sense to have a filter.
How does that sound? If you're interested in these changes I'd be happy to submit a PR. To give you an idea of what I'm thinking, here's how I'm currently getting the preload graphs for my entry modules (note: you do have to builds these graphs yourself, as this information isn't exposed by anything in
ChunkInfo
):The text was updated successfully, but these errors were encountered: