Gustaf Räntilä

Added required `id` to extendable components (as discussed in https://github.com/backstage/backstage/pull/11819#discussion_r888715834). If we get something like https://github.com/backstage/backstage/pull/10260 merged, it could show a list of extensions and which one of them that...

Thanks for the feedback @Rugvip! I think the main reasons for actually using _components_, rather middleware approach would be: * Middleware semantics are kind of broken similarly to callback based...

Playing around with this code, and thinking twice about that shortcut, I wonder if it would make more sense to only have `Component`. * If returned as is `return `...

Yeah, I think we're approaching this very similarly. Only having `Component` is extremely slick. Whether context providers are used or not can be entirely transparent to the API surface.

Removed `ComponentProvider` from the API, now `Component` has an optional `value` prop, so: To forward the component as-is: `return ` To change the context: `return ` Updating the PR message...

* Renamed extendable/extension adaptable/adaptation. Adaptation component `Provider` -> `Adaptation`. * Both adaptable components and adaptations themselves can now be lazy-loaded (dynamic import) * No forced opt-out, but either opt-in or...

Updated PR message to reflect the latest changes

Fixed the issue of having a versioned context keyed on component ref _objects_ (which could have multiple instances), into using the _id_ (string) instead. As [discussed](https://github.com/backstage/backstage/pull/11819#discussion_r888712111) with @kuangp, being able...

# [Renamed, refactored] Adaptable components The latest commits changes how these adaptable components are created in a big way, after discussions with the maintainers. Instead of having adaptable components have...

ping @backstage/maintainers, last push is a heavily simplified version, as discussed previously. I can rebase and fix conflicts if you feel confident this would suffice for merging.