-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃殌 Feature: Allow easier customization of header for EntityLayout #24623
Comments
Hey 馃憢 thanks for raising this! Wanna link to this previous discussion here for customizing components based on 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. |
@benjdlambert Thanks for the reply! I wound up forking |
馃敄 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 #16173 (comment)), 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!
The text was updated successfully, but these errors were encountered: