ToolsPanel: Selected ToolsPanel menu options are not persistent

[apeatling]

Prior: #41376

When using the ToolsPanel menu to select design tool options for a block, these selections are not remembered unless the value of a design tool setting has been selected. Simply setting the option as visible is not enough to persist it on block re-selection.

This GIF shows the issue:

[apeatling]

Persisting selected options has been discussed previously in #39561 (comment).

However this discussion was for persisting selected options across multiple blocks of the same type. That warrants caution, however persisting options in the same instance of a block is quite different. In my opinion this goes against user intent and expectation and should be added.

[mtias]

Curious how you'd expect it working after a reload — would you expect a non customized option you selected to show up? Holding onto the session state seems a bit superfluos to me, and I don't think it's worth the extra complexity of handling state that would persist through remounts but not through hard reloads.

[apeatling]

I don't think it is necessary to maintain state after a reload.

However, within a single session, I can see it being a confusion. I can see a user selecting the tools they need, but in the middle selecting a similar block to refer to a setting value. Then they come back to the block to find everything reset.

I haven't run in to this in my real world usage, so it is purely hypothetical on my part -- but it has been reported in the original issue.

[mtias]

I'd consider this low impact for the likely complexity it'd entail to keep track of unmounted component state. We can revisit if it becomes a wider concern.

[annezazu]

Re-opening this as it came up in a discussion with YouTubers with folks requesting this as an option. Specifically, that when an option is enabled that it persists in the future until someone disables it again for typography settings. I recorded a little video showing how this impacts my workflow with a specific example:

styling.options.typography.mov

Curious to hear from @WordPress/outreach as to whether this is something others run into.

[markhowellsmead]

Definitely. See also #62064.

[bacoords]

Big agree on this. There's a number of issues about the persistence of UI controls- it's a very common pain point for most users (There were some a11y concerns about some of them, but I believe they're addressable):

• Stay in the selected Sidebar (Inspector) tab when you switch blocks (for example the Styles tab) #51104
• Sidebar panel selection should persist between blocks #62064
• Add the ability to pin typography settings #45283
• Keyboard Shortcut: Toggling in/out of distraction free mode should remember open panels #59789

[annezazu]

Thank you all for chiming in and cross connecting. Excellent to get a broader spread and more thoughts. Keep it coming!

[markhowellsmead]

There's some great UX feedback in this post on X. What's the best way to get these included here in Github?

https://x.com/KatieKeithBarn2/status/1824362828251201966

[annezazu]

There's some great UX feedback in this post on X. What's the best way to get these included here in Github?

Open or find issues for each item :) Some of these already have issues opened.

[annezazu]

Noting that this came up once more today on a WordPress freelancer online meetup with folks talking about how frustrating it is to go looking for an option, turn it on, and then have it disappear when you move away to work on another block causing you to have to repeat the search cc @techmagick as you were a part of that convo <3

[ciampo]

Hey folks, in the context of potentially stabilizing the ToolsPanel component, I was reviewing related opened issues.

For this issue specifically, I think we need to make changes to both the ToolsPanel component itself, and to the logic in the inspector control sidebar:

• we may need to add functionality to the component to:
  • add an prop to set an optional ToolsPanelItem as visible (I believe that currently only "default" items are visible on first render)
  • add a callback prop so that consumers of ToolsPanel can be notified of which panels are shows and which are hidden
• in the inspector controls (or wherever the component is used), the information about which ToolsPanelItem was shows for each block can be stored and used to make such items persistent.

@WordPress/gutenberg-components @aaronrobertshaw how does this sound?

[aaronrobertshaw]

how does this sound?

Thanks for kicking off this discussion again @ciampo!

As per this comment, I'm not sure we've reached the threshold where the added complexity in tracking menu states is desirable. However, if it doesn't take too much to add the new functionality to the ToolsPanel component to support this in the future, then the plan sounds good to me and unblocks the proposed stabilization of the component 👍

[fabiankaegy]

@aaronrobertshaw @ciampo in chatting with @youknowriad a bit over the last week we thought about it this way:

1. Refactor any existing instance of the PanelBody in Gutenberg to use the ToolsPanel (Standardize Block Inspector Settings to use ToolsPanel - Tracking Issue #67813)
2. Standardize the usage of group on all tool panels to make it easier to expend these panels for third parties (Standardize the usage of the InspectorControls "group" slots for all ToolsPanel components we provide in Gutenberg #67814)
3. Ensure that any tool panel items tie into the defaultControls mechanism so we can control the visibility of all items ([WIP] Block Supports: Try stabilizing default controls to top-level property #67729)
4. potentially connect that default visibility to user settings so that their choices can be persisted

Does that make sense or are we missing something in there?

[aaronrobertshaw]

Standardize the usage of group on all tool panels to make it easier to expend these panels for third parties (#67814)

My initial impression here is this is back to front. Maybe my brain is fried after a long day so correct me if I'm wrong.

Group isn't really "used on tools panels". We have slot fills representing these groups. Those slots can render however they want and so group slots representing the block supports render their fills wrapped in a ToolsPanel. It sounds like #67814 wants to create a range of new slots for both common (settings) and random one-off use cases (filters).

This all sounds separate to the ToolsPanel component to me.

Ensure that any tool panel items tie into the defaultControls mechanism so we can control the visibility of all items (#67729)

The broader mechanism for defaultControls shouldn't impact the ToolsPanel component. It's up to the consumer to say whether a ToolsPanelItem should be displayed by default or not.

potentially connect that default visibility to user settings so that their choices can be persisted

@ciampo's proposal above would make this possible. With the increased proliferation of the ToolsPanel due to efforts such as #67813, it means we could have heaps of panels to have to track within user settings. This is where the concern regarding impact vs complexity comes in.

[fabiankaegy]

@aaronrobertshaw yeah sorry my numbered list really made it look like those steps need to happen in that order 🤦

I don't think any of these really depend on one another.

All I was trying to say is that maybe we should leverage the defaultControls work you are doing to persist which items are shown and which items are hidden here in the tools panels

[aaronrobertshaw]

All I was trying to say is that maybe we should leverage the defaultControls work you are doing to persist which items are shown and which items are hidden here in the tools panels

There might be some limited overlap between defaultControls and the persisting of menu options. I'm not 100% convinced yet whether that would extend beyond similar shapes of data.

Ultimately, the defaultControls mechanism isn't something that will persist these user-made selections. There'll have to be a separate feature to collect, persist, and merge them with defaultControls. In other words, there's not much that could be leveraged towards the new feature other than the defaultControls data itself as a base.

[fabiankaegy]

@aaronrobertshaw thanks for those insights :) That makes perfect sense.

I think both here and in #67813 I have been too implementation focussed.

At the end of the day, these are my feature goals that I am completely open on how we get there:

• All Block Settings & Styles should be grouped in relevant groups
• These groups would be standardizes as much as possible.
• These groups should all use the same UI
• Developers should be able to place additional components in any of these groups
• There should be a mechanism to control which controls are shown by default in any of the groups
• Users should be able to have the controls they want to see by default override what the developer thinks they should see by default

[ciampo]

Thank you all!

If I understand everything correctly, a lot of the features being discussed are not directly affecting ToolsPanel, and therefore the changes suggested above should still be enough, from the component's POV ?

[aaronrobertshaw]

That's my understanding @ciampo, your proposed changes cover what's needed from the component itself.

[ciampo]

Cool! Let's use #67954 to coordinate next steps and related timelines.