Open jslott2sigma opened 2 weeks ago
Hey :wave: thanks for raising this! Wanna link to this previous discussion here for customizing components based on props
. https://github.com/backstage/backstage/issues/16876
It's a pattern that we probably want to avoid moving forward, especially with the upcoming work with the frontend system #19545 which should allow of deeper customizations like this issue.
I know it's probably not the answer you're looking for right now, but we're actively working on the frontend system now for these exact issues.
🔖 Feature description
Provide the ability to either replace the header component in
EntityLayout
entirely or expose suitable building blocks so that developers can easily create their own version ofEntityLayout
.🎤 Context
There have been several issues opened in the past asking for greater customization of the
EntityLayout
header (#16173 , #10434, #5658) and a couple of PRs (#16629, #11870). In the various discussions (most notably by @freben in https://github.com/backstage/backstage/issues/16173#issuecomment-1422558918), the maintainers have mentioned that until the proper solution comes about (e.g. "a new component customization system") they have been quite sensibly pushing back against point fixes and instead recommending developers replace EntityLayout in its entirety.Customization of the EntityLayout header is of particular interest to us and subject to several feature requests we'd like to accommodate in the near term. Some examples of what we'd like to achieve are:
While previous work enabled partial customization (e.g
UNSTABLE_contextMenuOptions
), this issue proposes further work.✌️ Possible Implementation
Here are a couple of possible implementation paths:
HeaderComponent?: React.ReactNode
property toEntityLayoutProps
that if present, entirely replaces the built-in header.EntityLayout
.The benefits of the first approach is it entirely separates out the header concern from the layout/routing concerns of the page content. The custom header component would be responsible for constructing its own context menu, however, it is unclear if some of the existing handling/state of the unregister/inspect dialogs inside
EntityLayout
would interfere with an entirely-external implementation of the context menu.The second approach seems more in-line with what the maintainers have been recommending, and this option proposes to make it a bit easier. Perhaps we can expose the
useElementFilter
logic in hook? While it might be nice to also expose (in some way) the custom handling of the unregistering/closing of the various dialogs found inEntityLayout
now, that might be a secondary concern.👀 Have you spent some time to check if this feature request has been raised before?
🏢 Have you read the Code of Conduct?
Are you willing to submit PR?
Yes I am willing to submit a PR!