Sample for modules [lazy-loading] upon request

Question

In my application, I need to load the modules not at the initialization stage (by listing them in ./modules/modules ), but upon request later based on some condition (for example, user authorization results). Imagine that I want to provide User A with a calculator module and User B with a text editor module.

For simplicity, consider the sample templateplatejs application and assume that sampleModule1 and sampleModule2 should load on demand.

So, I remove the modules from the initial boot sequence in src \ modules \ modules.js:

  return [ require('./baseModule/module'), /*require('./sampleModule1/module'), require('./sampleModule2/module')*/ ]; 

and add the control to the summary page (src \ modules \ baseModule \ landingPage \ view.html) to load them upon request:

 <div> Congratulations! You are one step closer to creating your next large scale Javascript application! </div> <div> <select id="ModuleLoader"> <option value="">Select module to load...</option> <option value="./modules/sampleModule1/module">sampleModule1</option> <option value="./modules/sampleModule2/module">sampleModule2</option> </select> </div> 

Then I fix src \ modules \ baseModule \ module.js to pass the context to the LandingPageComponent object (for some reason, it is not in the source code):

  controller.addRoutes({ "/" : new LandingPageComponent(context) }); 

and finally add the download code to src \ modules \ baseModule \ landingPage \ component.js:

  $('#ModuleLoader').on('change', function(){ require([this.value], function(mod){ moduleContext.loadChildContexts([mod]); alert('Module enabled. Use can now use it.'); }); }); 

This seems to work, but the best way to do it?

Does it handle context loading correctly?

How to protect against loading the same module twice?

Answer 1

Clever thinking is here. I have worked too hard to upgrade BoilerplateJS to lazy modules as plugins the past few days. I did something similar, and you can access the POC code at:

https://github.com/hasith/boilerplatejs

In POC I did, I try to achieve “lazy loading” + “custom ui” at the same time.

• Each screen (called an application) is a set of components (plugins) placed on the layout. These application definitions are simply a JSON object that is either dynamically returned from the server API or statically defined as JSON files (as in POC). In POC, application definitions are stored in "/ server / application".

• These applications can now be called dynamically by convention. For example, "/ ## / shipping-app" will search for an application definition with the same name in "/ server / application".

• Downloading the application occurs through a new component, which I have in '/ modules / baseModule / appShell'. Any image with '/ ## /' will be directed to this component, and then will try to load the application definition by agreement from the "/ server / application" folder.

• When the appShell application receives the application definition (as JSON), it will also try to load the components (plugins) that are dynamically defined in it. These plug-ins are hosted in 'src / plugins' and will also be downloaded by agreement.

An example application definition would look like this:

 { "application-id" : "2434", "application-name" : "Order Application", "application-layout" : "dummy-layout.css", "components" : [ { "comp-name" : "OrderDetails", "layout-position" : "top-middle" }, { "comp-name" : "ShippingDetails", "layout-position" : "bottom-middle" } ] } 

The advantage of the approach is as follows:

• Application interfaces are managed by components and configured at runtime.
• It is possible that different application definitions are sent to the user depending on the role of the user, etc. (backend logic)
• Applications can be created on the fly by combining existing components.
• The “structure” does not require any static code changes to add new applications or components, since the download is based on consent

These are very initial thoughts. Rate any feedback!

Answer 2

You can protect against multiple module loading by using named functions for the change event and cancel the function after it is executed.