suddjian opened a new issue, #20615: URL: https://github.com/apache/superset/issues/20615
## [SIP-87] Proposal for Superset Extensions ### Motivation It is often desirable for a Superset distribution to add customized UI in Superset. For example: - A banner on the homepage with some org-specific content - A button in the navbar that does something specific to your installation - Adding new options to a context menu - Swapping out a configuration interface to implement functionality that is streamlined for your org Superset's options for frontend customizations (such as chart plugins) aren't flexible enough to cover these use cases. You could fork Superset to add your custom UI, but you get no confidence that your modifications will not conflict with future upstream changes. ### Proposed Change Add a flexible frontend customization framework allowing distributors insert custom extensions at points defined by Superset. Add an `extensionsRegistry` module to `superset-ui/core`. Each extension defined for this registry has a key, and a type of value that can be registered at that key. Superset can look up whether an extension is registered, and use the extension where appropriate. _This is really just a fancy way of saying we have an object which exposes fields that can be set by outside code._ But it's well typed though! Forks can alter the `setupExtensions.ts` file to add their extensions. In vanilla Superset this file will just export an empty function. This registry differs from the previous registry pattern used in Superset e.g. the `ChartComponentRegistry`. The old registry acts like a dictionary: keys are arbitrary, and all values are of the same type. This doesn't work well for extensions, where the contract of each one depends on how it is intended to be used. In the new `TypedRegistry`, all keys are defined explicitly, and the value corresponding to each key has an explicit type. Different extensions can have different types. You can have a react component, a function, a string, or whatever you need, and it's all well defined in typescript. Only one value can be registered with each key. If an extension point should work with multiple values, we can define a list or dictionary under that extension's key. The goal here is simplicity and flexibility. Extension points will be part of Superset's public API, so their contracts can only be broken in a major release. With that in mind, extension points should be added with care: Changing names or removing things would be a breaking change. Committers should carefully consider the semantics of the name, and the contract of the extension point, before adding one. ### New or Changed Public Interfaces Technically everything proposed here has already been merged and tested out. It's a pretty small, simple change. This is more of a proposal to make the pattern an officially supported Superset Thing. No changes required really, except documentation. ### New dependencies N/A ### Migration Plan and Compatibility N/A ### Rejected Alternatives **Using the existing registry pattern instead of adding an extensions registry:** The plugin registries are designed to accommodate an arbitrary collection of objects, all conforming to the _same_ interface, with _unknown_ keys. This doesn't fit the needs of an extensions system for modifying frontend behavior. For an extensions system, it is more helpful to have known keys to register extensions, and a diverse interface where each defined extension point offers a specific interface independent of other extension points. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
