Currently, all our plugins are contained in a PluginsModule. The PluginsModule is statically referenced by the main app, and the PluginsModule in turn references each plugin through its EntryComponents section. This is because webpack will drop these components during tree shaking if they are not referenced as an EntryComponent. Therefore, although we do use a System.import to "dynamically" import the plugins, these are faux plugins at best and the idea was always to separate them out completely as the Angular ecosystem matured.
We are now probably at a stage where the Angular 5 ecosystem can handle this situation much better. There are good guides [1, 2] on how to package components using rollup and publish them to npm.
However, the best technique for dynamically loading such components is less clear. This is because these packaged components are typically installed from npm, referenced by the main app and the final client js files created through webpack. Instead, we need to directly package the module for consumption by the client using a dynamic module loader, such as the SystemJSNGModuleLoader, as described in this guide here. This means that we should probably be able to compress and package the plugin using webpack or similar, and publish it to a url somewhere, so that it can subsequently be loaded on the client with something like:
System.import('/url/of/webpacked/plugin/module')
Using webpack is probably desirable because we can use hot module replacement etc. to support multiple versions of a plugin.
These are some desirable characteristics:
[ ] Provide a seed project that can serves as a template for creating a CloudLaunch front end plugin, with support for packaging it using rollup and support for publishing the final plugin to npm.
[ ] Each PlugIn should be an Angular Module which can contain multiple components
[ ] Plugins should be composable in nature (e.g. The GVLPlugin uses the CloudMan plugin)
[ ] Plugins should be statically usable on the server side and we can start off that way
[ ] Later, we should provide a mechanism for directly loading a plugin on the client.
[ ] It would be nice if multiple versions of a plugin could be loaded simultaneously on the client (e.g. On the "My Appliances" page)
[ ] There should be a simple mechanism for developing the plugin locally
[ ] Plugins should have a test harness so that they can be individually tested
[ ] It would be nice to be able to run plugins without having to publish to npm, say directly off a git repo.
Currently, all our plugins are contained in a PluginsModule. The PluginsModule is statically referenced by the main app, and the PluginsModule in turn references each plugin through its EntryComponents section. This is because webpack will drop these components during tree shaking if they are not referenced as an EntryComponent. Therefore, although we do use a System.import to "dynamically" import the plugins, these are faux plugins at best and the idea was always to separate them out completely as the Angular ecosystem matured.
We are now probably at a stage where the Angular 5 ecosystem can handle this situation much better. There are good guides [1, 2] on how to package components using rollup and publish them to npm.
However, the best technique for dynamically loading such components is less clear. This is because these packaged components are typically installed from npm, referenced by the main app and the final client js files created through webpack. Instead, we need to directly package the module for consumption by the client using a dynamic module loader, such as the SystemJSNGModuleLoader, as described in this guide here. This means that we should probably be able to compress and package the plugin using webpack or similar, and publish it to a url somewhere, so that it can subsequently be loaded on the client with something like:
Using webpack is probably desirable because we can use hot module replacement etc. to support multiple versions of a plugin.
These are some desirable characteristics: