In both cases below, ID
is the exports object of the "id"
module.
require.ensure(["id"], function (require) {
var ID = require("id");
})
- In this example, the
"id"
module does not need to be loaded before executing this module. Because it uses therequire("id")
syntax, it is not simple to distinguish it from a dependency that must be preloaded.
require.async("id", function (ID) {
}, function (error) {
});
- does not accept multiple identifiers. The presumption is that it will be more common and usable for the loaded module to statically depend on anything you would be tempted to import in the same async call. If this presumption does not pan out (in my own use, it has), it is easy enough to extend this specification with spread/rest (variadic) arguments.
@cadorn As for the name, it was a bike-shed because some participants felt that it didn’t read well. I disagree. Your current form resembles Tobie’s Async/A Draft 2 Proposal, and shares the flaw that the inner
require
is not easily distinguishable from an outer, static, require. UncommonJS/Modules are still firmly in the world of statically analyzingrequire()
calls instead of declaring them up front.My thought about the
load
name is that it would load but not execute.require
has always implied async preload and execute.