You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2022/07/06 02:09:39 UTC
[GitHub] [superset] suddjian opened a new issue, #20615: [SIP-87] Superset Extensions
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: notifications-unsubscribe@superset.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] Semiotikal commented on issue #20615: [SIP-87] Superset Extensions
Posted by GitBox <gi...@apache.org>.
Semiotikal commented on issue #20615:
URL: https://github.com/apache/superset/issues/20615#issuecomment-1374516293
hey saw that a class for this was made as proposed. Any docs on this (or if no docs, would love any tips on how to make use of this extensions registry)
--
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: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-87] Superset Extensions [superset]
Posted by "rusackas (via GitHub)" <gi...@apache.org>.
rusackas closed issue #20615: [SIP-87] Superset Extensions
URL: https://github.com/apache/superset/issues/20615
--
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: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-87] Superset Extensions [superset]
Posted by "rusackas (via GitHub)" <gi...@apache.org>.
rusackas commented on issue #20615:
URL: https://github.com/apache/superset/issues/20615#issuecomment-1945295274
Closing this as dismissed... I'm not seeing any record of SIP process going through on this (I might be missing it) but this `extensionsRegistry` does indeed exist today. I guess we'll call this discarded on the SIP board, but please feel free to discuss if this needs more attention @eschutho @michael-s-molina @john-bodley
--
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: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org