prefetch dynamic modules when appcache is active #9482
Conversation
| // If we call module.prefetch(id) multiple times in the same tick of | ||
| // the event loop, all those modules will be fetched in one request. | ||
| function prefetchInChunks(modules, amount) { | ||
| var promises = Promise.all(modules.splice(0, amount).map(function (id) { |
There was a problem hiding this comment.
var promises is unused, so I'm thinking you can just remove it?
|
|
||
| // If Package.appcache is loaded, preload additional modules after | ||
| // the core bundle has been loaded | ||
| if (Package.appcache) { |
There was a problem hiding this comment.
Let's move the check for Package.appcache inside the window.onload callback, just in case the appcache package loads after dynamic-import.
There was a problem hiding this comment.
Also, in order to make the window.onload event registration compatible with all browsers, I would do something like this:
if (global.addEventListener) {
global.addEventListener("load", handler, false);
} else if (global.attachEvent) {
global.attachEvent("onload", handler);
}There was a problem hiding this comment.
I'll make these changes - what version of IE does Meteor try to maintain support for? Any thought to using something like http://github.com/Raynos/DOM-shim ? It would allow us to remove forking code like this and still allow users who need IE8 and lower a way forward.
Also (this is more for my education) - is global a meteor variable?
There was a problem hiding this comment.
Also, do you think it'd be worth exporting flattenModuleTree - and have client.js (which now includes a copy of that function) consume that? Alternatively, I could more specifically tailor the copy I added to dynamic-versions.js and just leave it copied (or just leave it as is).
There was a problem hiding this comment.
Also (this is more for my education) - is global a meteor variable?
There was a problem hiding this comment.
Yep, global is going to be standard ECMAScript eventually, and in the meantime the meteor package defines the global variable for all environments here.
I think this code is low-level enough that it's worth hand-coding cross-browser code, rather than bundling a library that we'd only use a part of. Likewise, I would support tailoring flattenModuleTree to the needs of this PR, especially if you see any opportunities to shorten/simplify the code.
There was a problem hiding this comment.
It's a minor change to flattenModuleTree - I could make it spit out the array I use directly, instead of converting that from the flat object it currently creates - it would use a bit less RAM, so I'll make that change.
| }) | ||
| } | ||
| // Get a flat array of modules and start prefetching. | ||
| prefetchInChunks(Object.keys(flattenModuleTree(versions)), 20); |
There was a problem hiding this comment.
Should amount be configurable?
There was a problem hiding this comment.
That's a good question, but I'd like to wait and see if people need the configurability. That said, I think I am going to bump this up to 50.
…tly (fewer mutations/less memory)
| if (global.addEventListener) { | ||
| global.addEventListener('load', precacheOnLoad, false); | ||
| } else if (global.attachEvent) { | ||
| global.attachEvent('load', precacheOnLoad); |
There was a problem hiding this comment.
This should be onload instead of load (but only for global.attachEvent). Thanks, IE.
There was a problem hiding this comment.
Ooph! Good catch.
This prefetches modules into the cache when the
appcachepackage is detected.As described in meteor/meteor-feature-requests#236
Couple of notes:
flattenModuleTreefromclient.js- I'm sure there's a better way to do that