Runtime plugins
Modify source logic without rewriting the source code!
Last updated
Was this helpful?
Modify source logic without rewriting the source code!
Last updated
Was this helpful?
Mosaic introduces the concept of "plugins". This is a feature of .
A plugin is a proxy between the original function (or object) and the function caller (object user). A plugin intercepts invocation of the original function and has control over the arguments and retrieved return value
Also conventionally called ".plugin.js" files, are the most important part of any extension. Because that's where the plugging logic is declared!
An instruction to the plugin system in pseudocode looks as follows.
In order to make this code actually do something in your application, you will need to change , and to values relevant for your application. The process of getting these values is described below in this guide.
In order to declare a plugin, some preparations are necessary. First of all, an extension module must be . You will implement your plugin there.
For the development purposes, it's recommended to have the under-development extension module into your project.
Then, you should create a plugin declaration file in the . The guide below describes the process of implementing logic in this plugin declaration file.
If you are willing to create
Plugin system should know the kind of the piece of functionality you are trying to interact with. There are several such kinds.
Currently, the following targets are available for modifications through the plugin system:
function - for functions declared both via regular and arrow syntax, not belonging to any class
member-function - for functions declared either as regular ES6 class members or as class properties (arrow functions)
member-property - for class members declared via class property syntax (but not for functions!)
static-member - for any kind of static members
For every target kind apart from function, it is necessary to determine the name of the member you are willing to interact with. All of these target kinds are related to classes, and the names of their members will be taken for this purpose.
Such a proxy function has full control over the call of the target that you are plugging into. Hence, you can modify arguments passed to it, modify the return value, decide on whether to call the original member or not (you usually are required to, see a warning below)
An array of args
from the caller
callback
- the original function (or the next plugin)
context
- the original context of a function
Not calling the callback
will prevent the initial logic from being called, thus overwriting it completely. Such an action makes your plugin much less compatible with any other plugins.
This is not recommended, but if critically necessary - do this only acknowledgedly and on your own risk.
In order for a plugin declaration file to have impact on the application, it should export a piece of configuration that will be consumed by the plugin system. See the structure of such a configuration in the example below.
Each plugin has a target to "plug into". This target is determined by a . Namespace should be present in the your source, which you are willing to change. If your source lacks such a namespace - put it there!
Remember to have the source module in order for namespace comments to be handled correctly by our
Each expects a function with a different set of arguments. Below is an overview of function implementations for each proxy type. Each of these plugins solely invokes the original functionality, thus leaving the application intact.
Note, that the variables called pluginX
are proxy functions .