Dataviews Filter search widget: do not use Composite store

[ciampo]

What?

Extracted from #64723

Refactor the dataviews filter search widget so that it doesn't use the store from useCompositeStore to function.

Why?

See #63704 (comment)

How?

By controlling the activeId state via props, and reacting to the onFocusVisible callback

Testing Instructions

There shouldn't be any noticeably different behaviors — make sure that the following happens both in trunk and in this PR:

• Open the site editor, select "Pages" from the sidebar
• Click on the filter icon, and select "author". A dropdown menu should open
  • Make sure that, when the menu opens, no "author" option is highlighted
  • Press tab. Make sure that, as focus moves onto the list of possible "author" choices, the first item in the list gets highlighted
• Repeat the process, but for the "Status" filter
  • Make sure that, when the dropdown menu appears, the first item is automatically highlighted

Screenshots

Kapture.2024-09-02.at.18.09.44.mp4

[github-actions]

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: ciampo <mciampini@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>

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

[ciampo]

e2e test failures seem related — will look into it

[tyxla]

e2e test failures seem related — will look into it

Yeah, seems like we're not exporting Composite.Typeahead and Composite.Hover as private APIs. Fixed in 7c7975b.

[tyxla]

Should we directly pass the filter.elements[ 0 ].value? Seems like only the value is necessary to construct the ID. Could potentially simplify the second argument type, too.

[tyxla]

We were previously working with defaultActiveId and not activeId. Are we certain this won't introduce suble differences?

[ciampo]

We are using to activeId instead of defaultActiveId since we are switching from using Composite uncontrolled, to controlling its active item ID state.

I moved the defaultActiveId value to the initial state value for activeCompositeId.

I'll look more into it, and report any findings

[ciampo]

This logic affects the composite widget when opening the dropdown — it basically prevents Composite from automatically picking an active composite item if there is more than one filter operator.

I reviewed the code, and I don't think this change will introduce differences in the current state of the code since the filter.operators array doesn't seem to change while the dialog is open.

If this assumption was ever going to change, I suspect the previous version would have also incurred in some unexpected behaviour

[ciampo]

In general, the current implementation feels a bit hacky. I wish we didn't have to control the activeId state at all. With more time and and a willingness to tweak this UI a bit, we could also consider having different styles for active vs focused items.

But not in the scope for this PR, and without a high priority.

[tyxla]

Tests well and code LGTM, thank you 🚀