-
Notifications
You must be signed in to change notification settings - Fork 8
Open
1 / 11 of 1 issue completedDescription
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
Labels
No labels
Type
Projects
Status
Backlog