是否有一种设计模式/系统，用于延迟加载捆绑的AMD模块而不加载我已经下载的模块？

Question

Suppose I have a large single-page application which is built around AMD modules. When the user first visits the front page of this application, we want the initial JS payload to be reasonably light so we only load the minimum JS to set up the app and load the front page. From there the user can do "Action A" or "Action B". Each "action" requires new modules ( "module_a" and "module_b" repectively) to be loaded.

module_a 's dependencies are module_a_1 , module_a_2 , module_a_3 , and module_X module_b 's dependencies are module_b_1 , module_b_2 , module_b_3 , and module_X

Notice that both modules depend on module_X .

Now, if the user performs "Action A" we tell the server we want module_a . The server bundles module_a and all of its dependencies into the response. If the user performs "Action A" again, the client knows we already have module_a so it doesn't have to download anything new. That's easy.

But suppose the user performs "Action A" and a little while later, performs "Action B". Clearly we need to download module_b , module_b_1 , etc. but the client already has module_X . It would be a shame if module_X came bundled with the request for module_b because we already have module_X .

Is there a system/framework/pattern that supports the requesting AMD modules and their dependencies but not the dependencies the client already has, perhaps by somehow communicating to the server the modules the client has?

Answer 1

Is there a system/framework/pattern that supports the requesting AMD modules and their dependencies but not the dependencies the client already has, perhaps by somehow communicating to the server the modules the client has?

It seems you're missing the point of AMD, since that's exactly what it does -- if module_X is already loaded, there will not be another request to the server for module_X .

Reading between the lines of the question, I think you're not stating it properly. I think the situation is this:

You're not specifying all the module dependencies at the beginning of your module definition. Using nested inner requires, you're lazy loading some dependencies until the moment that they're needed. As a result, what you find is that the inner require loads dependencies you've already declared as part of your outer dependency, or as part of another inner require dependency.

If this is the problem, then the short answer is that the nested require needs the loading context of the outer require. This is done by specifying require itself as a dependency

require(["require", /* other deps */], function(require, ...){
   require(["module_a_1","module_X"], function(moda1,modx){ /*... */});
   require(["module_b_1","module_X"], function(modb1,modx){ /*... */});
}

This isn't very well documented in RequireJS's own documentation. See https://github.com/jrburke/requirejs/issues/173 for more details.