[RFE] Allow to remove default capabilities/routes

[joaquimrocha]

Current situation

We allow to create and even replace routes through plugins, but we don't allow to remove them.

Impact

There may be vendors that do not want to offer a certain route or entry in the sidebar.

Ideal future situation

We have a way to remove a route and entry in the sidebar. Maybe also other features, like default header actions, sections, etc.

Implementation options

One way would be to allow "deregistering" routes/sections/etc. But this is TBD. Suggestions are welcome.

[joaquimrocha]

I have been thinking about how to accomplish this and would like to share a quick RFC for my ideas.

Generally instead of having a "registerSidebarEntryEraser" or "removeRoute", I was thinking we should offer the ability to set up filters for sidebar entries + routes. A filter as a name and a function, the function will receive the item in question and return either null or the item (modified or not). E.g.

   registerSidebarEntryFilter(filterName: string, filterfunc: null | ((entry: SidebarEntry) => SidebarEntry | null));
   registerRouteFilter(filterName: string, filterfunc: null | ((entry: Route) => Route | null));

This allows us to e.g. modify what a route's path is, or what a sidebar name is, without having to override them with the regular register function (thought that functionality remains, this just makes it simpler). If the filter function return null, then those routes or sidebar entries will not be considered anymore when rendering. i.e.

// Remove namespaces sidebar
registry.registerSidebarEntryFilter('no-namespaces', (entry) => entry.name === 'namespaces' ? null : entry)
registry.registerRouteFilter('no-namespaces', (route) => route.path === '/namespaces' ? null : route)

The filter function can be null so we effectively remove the filter (which may be needed).

// Remove namespaces route filter (leave the sidebar one though)
registry.registerRouteFilter('no-namespaces', null)

Of course, returning just the argument in the filter means also not filtering it at all, but I like the idea of actually dropping the filter from memory...

I wonder what we should do for things like e.g. removing the cluster selector button, or the theme change button, if we need that too. Should we have that as a filter function for other parts of the UI/functionality, or should we have a settings object and we allow plugins to manipulate that for turning off (or on) parts of the UI.

Comments are welcome.

[illume]

Took me a little while to grok what filter did here.

What happens when multiple plugins are doing their business?

• Plugin A, adds a filter.
• Plugin B, adds a filter.

[joaquimrocha]

plugin B will consume the routes that have been already filtered by plugin A. Otherwise I don't think the functionality would make much sense. This gives a lot of power to plugins, but arguably just slightly more than what they can already do (since they can override routes already).