The following are some of the most used approaches to handle pluggability on frontend:
- The main application works like a layout for all the features it contains, where each feature has switch on/switch off functionality. If a plugin is present, it will be displayed in a certain place. But, if you want to develop a new plugin, you will need to modify the main application, so it will be aware about it.
- Load plugins dynamically and add them to the main application as sub-applications in an iframe. That gives certain flexibility, as you can use different versions of the same third-party libraries, but there are also some costs, including:
- The bundle size blows really fast. All required third-party plugins have to be included inside the plugin again.
- To reuse already written logic in a core plugin, you either have to copy and paste it or create a shared-module with common functionality and include it in the core and custom plugin. In this latter scenario, when this shared functionality is different from plugin to plugin, it can become a mess really quickly.
- It will not allow you to bring smallchanges to an application, like replacing a button with a new one on the fly.
Keeping these limitations in mind, let’s have a look at a new approach. First, I will explain it with a simple example and then on a more advanced level.
