-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor the colors UI in the inspector to use the navigator approach #36952
Conversation
Size Change: +735 B (0%) Total Size: 1.1 MB
ℹ️ View Unchanged
|
|
||
{ hasTextColor && ( | ||
<NavigatorScreen path="/text"> | ||
<ScreenHeader back="/" title={ __( 'Text' ) } /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These "back" links need the ability to focus the element they represent when you go back, otherwise the top one is always selected. This also happens in global styles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mmm, this might not be easy without introducing some kind of #hash
support in the "path" since the original element is remounted entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the NavigatorScreen
had the ability to move the focus on itself (or on a children) when mounted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me the only to know the element that was focused before moving to a new "screen" is:
- Keep a reference to the old element
- Or have an identifier for the element.
We don't render all the screens at the same time, meaning, even if keep a reference, when going back to the previous screen, new elements will be rendered so that reference that was kept is useless.
Meaning, we only have one option: add identifiers to elements and pass the identifier somehow to navigator.push
calls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can explore keeping hidden screens mounted
That would be a huge performance degradation for Global Styles, there are hundreds if not thousands of screens (blocks...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would moving the focus on the new "screen" (instead that on the precise link) be an acceptable compromise? That would simplify the solution considerably (we'd just need to add the option for a screen to auto-focus when mounted)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's move this conversation into an issue specifically for global styles, since we might not end up doing anything here on the block inspector.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I've opened #37063
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This PR will benefit from a few things happening separately:
Here's what's left: The focus handling is already being discussed. So what remains after that is managing the hierarchy and treatment of the "Background" subheading, the border below, and the margins/paddings that make this panel look a bit compressed. I'll dive in and see if there's any small and clean tweaks I can push there. |
I pushed a small change to absorb the double padding: It's hard to do this without a little bespoke CSS (see 29c49a8), because:
I took the liberty of pushing the code, but feel free to comment on whether there's a better way to accomplish this. One thing that I had to unset was an Depending on whether we can accept these changes, my next fix would be to polish the back button and the subheading. |
Seems very complicated (and maybe a dangerous precedence) to mix the accordion with the drill down. This could lead to having multiple accordions each with their own drill down, which seems to add a lot of cognitive overhead. |
Going to close this one for now, I think we should land #37053 instead for 5.9. |
This begins to implement the ability to group color elements in the block inspector based on the design flow of #34574.
This is just a naive approach to see what it would give as a result.