Context
Current problems:
No
Decission
If we want OpenSCD to be extendable, we should allow OpenSCD to support `addons`. An addon is like a plugin, but without the requirement of needing to extend from `HTMLElement`. An `addon` is a default exported function from a file.
an `addon` function gets the `OpenSCD` class as a parameter. from here, it can fetch the document if needed. it can also subscribe to events dispatched to `open-scd`.
By implementing addons, we can minimize the risk of people forking OpenSCD and adding new functionality. If people want extra functionality on OpenSCD, they can create an addon for it.
export default function xsdValidate(openSCD: OpenSCD) {
openSCD.addEventListener('validate', (evt: ValidationEvent) => {
const { doc } = openSCD;
// Do actual validation to the doc.
});
}
Another option is to support a new kind of plugin, `background` plugins. These plugins are rendered upon document load, like the `menu` plugins. Except these plugins are not shown in the UI. These plugins use the dom for dependency injection.
When `addons` or `background plugins` are supported, it will be possible to migrate current mixins from OpenSCD into `addons` or `background plugins`.
An `addon` is a function that's not depending on anything.
The `addon` function gets the `OpenSCD` instance class as a parameter.
Alternatives
Background plugin
Pros
It can use the current `plugin` mechanism to load.
Cons
- A background plugin is extending from `HTMLElement` but it's not rendering anything. This goes against the `CustomElement` principles.
- The dom can get polluted quickly by creating background plugins
Conserquences
`Addons` need to be loaded apart from `plugins` .