Skip to content

feat: Add grouping support to plugins.json #38

@stee-re

Description

@stee-re

Option 1 - Constrain nesting to one level:

  • Simpler paradigm from a UX perspective
    • Less UX edge cases to consider
  • Maybe a disadvantage for distros with a very large number of menus or editors (limited structuring)

Serving suggestion:

export interface PluginBase {
  name: string;
  translations?: Record<string, string>;
  icon: string;
}

export interface Plugin extends PluginBase {
  tagName: string;
  requireDoc?: boolean;
}

export interface PluginGroup extends PluginBase {
  plugins: Plugin[];
}

export type PluginSet = {
  menu: (Plugin | PluginGroup)[];
  editor: (Plugin | PluginGroup[)];
  background: (Plugin | PluginGroup)[];
};

Option 2 - Allow multiple levels of plugin nesting:

  • more flexibility
  • potentially more future proof???
  • opens can of worms on the UX where nesting is in theory open ended.
  • potentially higher risk of UX edge cases we might have to handle/test/support (even if one on in their right might would reach such edge cases)

Serving suggestion (note, only difference from above is the type specified for the PluginGroup.plugins)

export interface PluginBase {
  name: string;
  translations?: Record<string, string>;
  icon: string;
}

export interface Plugin extends PluginBase {
  tagName: string;
  requireDoc?: boolean;
}

export interface PluginGroup extends PluginBase {
  plugins: (Plugin | PluginGroup)[]; // <- Only change needed to go from Single level nesting to n-deep nesting
}

export type PluginSet = {
  menu: (Plugin | PluginGroup)[];
  editor: (Plugin | PluginGroup)[];
  background: (Plugin | PluginGroup)[];
};

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions