Avatar: Refactor settings panel to use ToolsPanel

[Infinite-Null]

Part of: https://github.com/WordPress/gutenberg/issues/67813

What?

Refactored Avatar Block code to include ToolsPanel instead of PanelBody.

Screenshots:

Before	After

[github-actions[bot]]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Infinite-Null <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: fabiankaegy <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

Hi, @Infinite-Null

Do you have time to follow up on this PR?

[Infinite-Null]

Sure @Mamaduka

[Infinite-Null]

Hi @Mamaduka and @t-hamano , I’ve made the necessary changes and moved the conditional addition of settings to the very end so that it matches the expected order. Please let me know if there’s anything else I should update!

[t-hamano]

moved the conditional addition of settings to the very end so that it matches the expected order.

I don't think this is an ideal solution. This may be a problem that should be fixed on the ToolsPanel component side.

For now, I personally prefer to accept this issue and prioritize the migration to the TooslPanel component. See https://github.com/WordPress/gutenberg/issues/67813#issuecomment-2907556825

@Mamaduka @fabiankaegy What do you think?

[Infinite-Null]

Sure @t-hamano, I have reverted my refactor changes 😄

[Infinite-Null]

Sure @t-hamano 🎉

[Mamaduka]

For now, I personally prefer to accept this issue and prioritize the migration to the TooslPanel component

Makes sense. Retaining correct ordering is a general SlotFill issue.

[Mamaduka]

A small interesting observation regarding ComboboxControl. I noticed that resetting the userId value to undefined doesn't clear out the combobox selection. It works if I change the reset value to null.

This could be an intentional side-effect or a bug. I think it's worth investigating separately, if we can reproduce the same problem in isolation. cc @WordPress/gutenberg-components

Screencast

https://github.com/user-attachments/assets/0ae33c71-6487-40b6-86b7-eec4abf56a98

[ciampo]

@Mamaduka I'd have to look deeper into the code to let you know whether this is working as intended or a bug — but, at least philosophically, it does follow the controlled/uncontrolled pattern that we've implementing rencently on some component: when a component is controlled, "no value" should be expressed with null (and not undefined).

[t-hamano]

it does follow the controlled/uncontrolled pattern that we've implementing rencently on some component: when a component is controlled, "no value" should be expressed with null (and not undefined).

After looking into this, it seems like this is indeed intentional behavior.

The ComboboxControl component uses the useControlledValue hook internally. In the useControlledValue hook, if the value is undefined, it is considered to be in an "uncontrolled state":

https://github.com/WordPress/gutenberg/blob/386df007aa1bf7bee05584d4cb1c45a32ece0d68/packages/components/src/utils/hooks/use-controlled-value.ts#L26

Related PRs:

• https://github.com/WordPress/gutenberg/pull/33039
• https://github.com/WordPress/gutenberg/pull/42403

[Mamaduka]

That makes sense, thank you both for the feedback.