Plugin development improvements

[joaquimrocha]

Right now, the way plugins are coded is: they call register* methods to register functionality they want to add/override.
There are two ways of calling these methods: either they are called after defining a Plugin class, or they are called directly in the module/file of the plugin. Since the latter is simpler, it is the only one we have been advertising for a while.
Headlamp thus loads the plugins by eval'ing their code. Moreover, the registered functions are kept in Redux, for a quick access.

This approach has a couple of issues:

1. Loading is initialization: whenever we load the plugin's code that has the register* methods "loose" in the file, it runs all register functions right away; there is no way to plan calling certain of those register functions at a later point; or to easily get the plugin to have initialization/destruction methods.
2. Since we call register* without any context about the plugin, it is not possible for Headlamp to understand which plugin is calling that method; of course we could require a plugin name to be added to the method, but this would make it trivial for a plugin to "pretend" to be another one. This impedes e.g. understanding what parts of the UI the plugin may attempt to change, so we could e.g. wrap a plugin's added header action in a div that tells which plugin has added that action, when in dev mode.
3. Setting the registered methods in Redux is not recommendable since Redux warns about those functions not being serializable.

So I would like to kickstart a discussion about how we could make this more controllable from Headlamp's side.

Proposals:

Classes

If we define a plugin as a class, we can require the registered functionality to be declared as instance variables instead, e.g.:

class MyPlugin() {
  headerActions = {
     processor: (actions: HeaderAction[]) => {
      // Do some processing
      return actions;
    }
  };
  sidebar = { items: [
    {
       ...
    }
  ]};

  ...
}

export default MyPlugin;

Pros:

We are thus able to solve the problems above in the following way:

1. -> Since the methods are now assigned, they will not run when the code is imported/eval'ed.
2. -> Since the methods are defined as variables, we control when and how we are calling them, so we can catch exceptions and mention the plugin's name in the error message, create a dev mode for Headlamp (wrapping UI components in divs related to the plugin, for quick identification), etc.
3. -> We don't need anything in Redux, we just need to keep the list of plugins, and when we need to e.g. run the header actions' processor, we just go through each plugin and run the method.

Cons:

• The class structure may be more complicated to understand for less experienced users.
• We lose the ability to dynamically register certain functionality, i.e. we lose the ability to do:

  if (some_condition) {
    registerHeaderAction(...)
  }

  So we'd have to move this logic into the method itself, or something similar, but we do lose some control on the developer's side here.

Object

This would be similar to a class definition, but we'd define an object instead:

MyPlugin = {
  headerActions: {
     processor: (actions: HeaderAction[]) => {
      // Do some processing
      return actions;
    }
  },
  sidebar: {
    items: [
      {
         ...
      }
    ]}
    ...
};

export default MyPlugin;

Pros

• Same as with the class, and...
• Simpler syntax than the class, may be friendlier to users unfamiliar with the code base.

Cons

• Same as with the class, and...
• Maybe we lose some encapsulation ability we have in the class, like:

  sidebar: {
    processor: () => {
      const myPluginStore = this.configStore() // <- getting the configStore without passing the name of the plugin (because we do this automatically) is nice
    }
  }

Code Interception

I noticed that VSCode does some module intercept so even when plugins call methods (not defining, calling) VSCode knows who is calling them.
AFAIU, if we did this, then we could maintain the current register* methods while basically providing different versions of methods for each plugin. So we'd fix issue 2. Issue 3 could also be solved, but we'd still have to deprecate the previous functionality since running register methods would rather mean defining methods to be run later.

So let's discuss some of these or any new ideas you may have for making the plugin system even more powerful!

[jda258]

Thanks for the clear explanation and description of possible solutions @joaquimrocha. I don't think you'll have to worry too much about the differences between using classes or objects for plugin developers as long as there are clear instructions.

[mattaurus]

The class approach is a good improvement. It makes the contract between plugins and headlamp core better to understand and validate.