You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 of EntityLayout.
馃帳 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:
Customize the left-hand title area text and layout entirely
Customize the "entity labels" area entirely (or remove entirely)
Customize the context menu icon and its menu items per-user or per-entity
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:
Add a HeaderComponent?: React.ReactNode property to EntityLayoutProps that if present, entirely replaces the built-in header.
Expose suitable building blocks to let developers more easily create their own 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 in EntityLayout now, that might be a secondary concern.
馃憖 Have you spent some time to check if this feature request has been raised before?
Hey 馃憢 thanks for raising this! Wanna link to this previous discussion here for customizing components based on props. #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.
@benjdlambert Thanks for the reply! I wound up forking EntityLayout for now to entirely replace the header and context menu. Glad to hear the new front-end system will handle this issue, looking forward to trying it out!
馃敄 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: