Proposal: Extension Structure

[Wolvan]

I propose the following structure for XKit 8 extension:

ES6 Module

BaseExtension.js

class XKitExtension {
  constructor(XKit) {
    this.api = XKit;
  }

  get __meta() {
    return {
      Name: 'Unnamed',
      Version: 'X.Y.Z',
      ShortDescription: 'Base Extension',
      Description: 'The base class for XKit Extensions',
      Authors: ['new-xkit'],
    };
  }

  get __preferences() {
    return [
      {
        Name: 'Preference 1',
        default: true,
      },
    ];
  }

  async install() {
    // The extension has been installed for the first time
  }
  async reinstall() {
    // The extension has been installed before but has now been reinstalled
  }
  async update(previousVersion, currentVersion) {
    // The extension has been updated to the latest version
  }
  async start() {
    // The extension is being loaded by the framework as part of boostrap
  }
  async stop() {
    // The extension is being unloaded
  }
  get api() {
    return {}; // Functions that are going to be called by other Extensions are set here -> Sandboxing
  }
}

XKit Extension:

class DemoExtension extends XKitExtension {
  update(prevVersion, currentVersion) {
    console.log(`You have succesfully updated DemoExtension from ${prevVersion} to ${currentVersion}`);
  }
  enable() {
    this.api.doStuffToTumblr();
  }
}

Questions to answer:

• Are all the functions necessary? For example is there a point to having an extension know it has been installed before?
• Are there any functions missing?
• What are the function signatures?
• What else should be put into the __meta block
• How do we handle defining preferences?

[nightpool]

Why have a class? When would an extension be instantiated more then once?

[Wolvan]

The reason I chose a class here is because it makes it easy to extend. If we were just using an object how would people best do inheriting from an object?

We do instance only once, you're right

[nightpool]

What does inheritance provide for us here? all i'm seeing is a single interface, so we could just, e.g., do export function install() instead of having a full class

…

On Fri, Aug 16, 2019 at 12:05 AM Wolvan ***@***.***> wrote: The reason I chose a class here is because it makes it easy to extend. If we were just using an object how would people best do inheriting from an object? We do instance only once, you're right — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AABZCV47C6RAKNFBJYZ4ABTQEYRQTA5CNFSM4IMCDBH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4NTHJI#issuecomment-521876389>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABZCV3HCQPAGXUGSJWRYD3QEYRQTANCNFSM4IMCDBHQ> .

[Wolvan]

The reason I went with a class is that we can modify the base class, add new functions and have all inheriting Extensions immediately work with the new system without them having to update.
We won't have to do any checks for "Hey, does this extension actually have this function?" because it will by inheriting the base Extension. It makes writing a loading and managing mechanism for it predictable.
Also I feel like instanceof is going to come in handy.

I also realized I forgot to make __meta static, that was an oversight.