DataViews: fix field reordering and visibility logic

[oandregal]

Part of #55083

What & Why?

This PR fixes a few issues around field reordering & visibility:

• Displays moving controls for combined fields. Combined fields could be reordered via the view config popup but lacked the same controls in the table header.
• Prevent fields that are part of a combined field from being displayed when they are listed in view.fields.
• Do not display hidden fields that cannot be made visible in view config.
• When view.fields is not provided: reordering fields should work.
• When view.fields is not provided: the properties panel in view config should be visible. Reordering & visibility was still available via the table header.
• When view.fields is not provided: display combined fields properly.

How?

Refactored the logic that deals with visibility & reordering fields.

Testing Instructions

Displays moving controls for combined fields

• Go to "Site editor > Templates" and switch to table layout.
• Verify the reordering controls are visible for combined fields.

Before	After

Prevent fields that are part of a combined field from being displayed when they are listed in view.fields

• Add title in view.fields for the Templates Page.
• Go to "Site editor > Templates" and switch to table layout.
• The expected result is that the title field (with Template label) is not visible in the table and the view config properties panel.

Before	After

Do not display hidden fields that cannot be made visible in view config

• npm install && npm run storybook:dev.
• Go to the default story for DataViews in storybook and verify the type field is not listed in hidden fields.

Before	After

When view.fields is not provided: reordering fields should work.

• Remove view.fields and view.layout.combinedFields for the Templates Page.
• Go to "Site editor > Templates" and switch to table layout.
• The expected result is that reordering fields works.

Before

240903-table-header-with-no-view-fields-before.mov

After

240903-table-header-with-no-view-fields-after.mov

When view.fields is not provided: the properties panel in view config should be visible

• Remove view.fields and view.layout.combinedFields for the Templates Page.
• Go to "Site editor > Templates" and switch to table layout.
• The expected result is that the properties panel within the view config is visible.

Before	After

When view.fields is not provided: display combined fields properly

• Remove view.fields for the Templates Page.
• Go to "Site editor > Templates" and switch to table layout.
• The expected result is that both the table & the properties panel display the proper fields (the combined template plus preview and author which are not part of any combination):

Before	After

[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: oandregal <oandregal@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>

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

[github-actions]

Flaky tests detected in 2c2d801.
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/10681307930
📝 Reported issues:

• [Flaky Test] Should insert content using the global inserter #57525 in /test/e2e/specs/widgets/editing-widgets.spec.js

[oandregal]

This actually stems from wanting to fix this issue #64381 (comment) but then I noticed there was a few other ones.

[youknowriad]

Prevent fields that are part of a combined field from being displayed when they are listed in view.fields

I feel we should be able to show the fields individually in separate columns if we choose to.

[youknowriad]

I think this works for now, but my thinking is that ultimately, we should find a way for the layouts to actually "inject" logic here. Or (which is what I had in mind) to have some kind of a slot and the "properties" area be specific per layout. For instance in "table", we should be able to "combine" fields if we want.

[oandregal]

I agree. If we aim to make the layouts "registerable/unregisterable" by 3rd parties we cannot have this kind of logic in the view config (or any other component).

I've looked at the current usage of layouts in this component and this is what I see:

• grid layout check to show/hide the density picker.
• table layout check to show/hide the ability to reorder fields.
• table layout check to inject "virtual fields" (aka combined).

All of them could be solved by providing a layout.supports thing somewhere. Using that approach, it'd still be DataViews' responsibility to define which "features" are supported.

Or (which is what I had in mind) to have some kind of a slot and the "properties" area be specific per layout. For instance in "table", we should be able to "combine" fields if we want.

This approach would be a lot more open. However, every layout would have to implement the same actions (reordering, visibility, etc.).

[oandregal]

In any case, not for this PR 😅

[oandregal]

Actually, layout.supports could also be a nice thing to have for consumers that want to "lock in" (aka remove options) a bit more the user experience.

[youknowriad]

This approach would be a lot more open. However, every layout would have to implement the same actions (reordering, visibility, etc.).

Yes, but for list view we have badges..., for grid we have columns and rows...

[oandregal]

Prevent fields that are part of a combined field from being displayed when they are listed in view.fields

I feel we should be able to show the fields individually in separate columns if we choose to.

I could be convinced otherwise, but I can't imagine use cases for this.

Anyway, if we wanted this, we should consider it at the user level (expose them in the view config under "hidden fields"). A feature that is related is the ability for users to "combine"/"split" fields. Not sure how both things would work together, so I'd rather leave this out of this PR.

[youknowriad]

I could be convinced otherwise, but I can't imagine use cases for this.

I agree that if we allow people to combine and split combined fields, it becomes kind of useless. I'm fine keeping the current state of the PR.

[jorgefilipecosta]

I have thoroughly tested the reordering and hiding functionality of patterns, templates, and pages view, and everything seems to be working well. I didn't encounter any unexpected issues with the code changes, so it looks like we can go ahead and merge this change. 👍