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: jorgefilipecosta <[email protected]>
Co-authored-by: ntsekouras <[email protected]>
Co-authored-by: oandregal <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: aduth <[email protected]>
Co-authored-by: poligilad-auto <[email protected]>

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

Flaky tests detected in 4c2556c.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/21350774613
📝 Reported issues:

• [Flaky Test] should allow setting page order to zero and negative values #74483 in /test/e2e/specs/site-editor/pages.spec.js
• [Flaky Test] should hide a block completely by selecting "Omit from published content" #74883 in /test/e2e/specs/editor/various/block-hiding.spec.js

Looks good. What do you think @poligilad-auto? Do we need the badge on non-collapsible cards too? I can go either way on that.

Separately I'm curious what it would it take for us to be able to use the new Badge from @wordpress/ui here? cc @ciampo @aduth. I'm assuming it won't be possible until ThemeProvider is adopted at a certain layer?

Separately I'm curious what it would it take for us to be able to use the new Badge from @wordpress/ui here? cc @ciampo @aduth. I'm assuming it won't be possible until ThemeProvider is adopted at a certain layer?

DataViews already embeds the base design token variables (some concern about this approach, but not a blocker for consideration here). There's still likely a need to incorporate ThemeProvider somewhere to effect theming like user color preference, but from DataViews perspective it should be possible to use these components now. DataViews already uses Stack, for example.

I too would be very interested in using @wordpress/ui Badge here and helping address whatever supports need to be in place to make that happen. Elsewhere, I'd proposed getting rid of the @wordpress/components Badge implementation altogether.

I will try to use @wordpress/ui here, here and share if there is any issue ☺️

The change to use @wordpress/ui is done, it was straightforward:

Can be tested at http://localhost:50240/?path=/story/dataviews-dataform--validation&args=layout:card.

Looks good. What do you think @poligilad-auto? Do we need the badge on non-collapsible cards too? I can go either way on that.

If the relevant error is already visible in the field, I don't think the badge is required on non-collapsible cards.

Looks good. What do you think @poligilad-auto? Do we need the badge on non-collapsible cards too? I can go either way on that.

If the relevant error is already visible in the field, I don't think the badge is required on non-collapsible cards.

Hi @poligilad-auto, @jameskoster thank you for reviewing this PR. I removed. the badge from the non colapsible panel.

Note this interaction:

• fill data that triggers error in control: error is displayed in control
• collapse the card: badge in card is displayed
• open the card to see the actions: the control no longer has the error

Can we perhaps leverage this technique to trigger the error in those scenarios?

Note this interaction: the bagde is visible immediately after having collapsed the card first. It results on sometimes the badge appearing immediately (if you had collapsed the card before) and sometimes appearing after collapsing. I suppose it's not a big deal, but I wonder: in collapsible cards, can we just display the badge every time there's an error? cc @jameskoster @poligilad-auto We could get rid of the touch-related code.

in collapsible cards, can we just display the badge every time there's an error?

You mean even if it's open? I don't love the inconsistency with non-collapsible cards, but maybe it's okay in the short-term.

What I find more concerning is this state:

The badge informs the user there's an issue, but none of the fields are marked. I think this is due to a separate issue and is being addressed elsewhere, but wanted to highlight just in case.

You mean even if it's open? I don't love the inconsistency with non-collapsible cards, but maybe it's okay in the short-term.

We already display the badge when the card is open, but only if the card has been collapsed before.

For example, this doesn't display the badge immediately:

But this does:

I was thinking that we should display the badge always, regardless of whether the card had been collapsed before or not.

I think this is good to land, thanks! Not sure if you want to wait for @oandregal to have another pass about the interactions, but I tested all the previous ones mentioned and seem to work nicely.

Thank you for the review @ntsekouras, and @oandregal, I will go for the merge, but I'm happy to iterate if we find anything needing improvements. I will also look at some issues in the input controls programmatic validation triggering separately.

Great work here, Jorge. The idea of reporting validity in the controls upon opening the card can be implemented in the panel as well. I've updated the tasks at #72321