DataFormPostSummary: fix different useSelect returned values

[ntsekouras]

What?

Follow up of: #76934

The linked PR introduced a warning for returning different values in useSelect: Non-equal value keys: entityData, entityIds. This PR solves that.

Testing instructions

1. Enable the Editor Inspector: Use DataForm experiment.
2. Edit a post and open the summary panel and the dev tools
3. no useSelect warning should be shown and editing should work exactly as before

Use of AI Tools

Opus 4.8 with direction, changes and review

[github-actions]

Size Change: -37 B (0%)

Total Size: 7.51 MB

📦 View Changed

Filename	Size	Change
build/scripts/editor/index.min.js	475 kB	-37 B (-0.01%)

_{compressed-size-action}

[Mamaduka]

@ntsekouras, can you share a bit more detail on why we need to "complex" data fetching here?

[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: ntsekouras <[email protected]>
Co-authored-by: Mamaduka <[email protected]>

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

[ntsekouras]

@ntsekouras, can you share a bit more detail on why we need to "complex" data fetching here?

What do you mean? Does it look more complex now?

By making the returned extra entities in a flat object we gain the shallowEqual checks for useSelect. availableTemplates are also used by the fields so I think it's fine to get separately.

With your comment though I noticed that availableTemplates can be fetched in the first useSelect and I updated that.

[Mamaduka]

After the split, useSelect logic is easier to follow, but there's still overall complexity in how everything is handled in this file. What's the main reason for handling ENTITIES logic this way?

I know this is a more complex implementation of the DataForm component, but how can we make it easier to work with?

Apologies for rambling; these thoughts are somewhat related. It's not a blocker, but it's worth considering.

P.S. Going to test this in a few and approve for merging properly.

[ntsekouras]

but there's still overall complexity in how everything is handled in this file. What's the main reason for handling ENTITIES logic this way?

Yeah, I definitely agree here! In the future we need to figure out a good API to properly support multi-entity forms and consumers shouldn't have to do anything like this. This exists right now only because of the lack of API, and the thing we gain is that the form for templates can omit these fields (if someone uses the filter for the view config).

[Mamaduka]

Can confirm that warnings are no longer triggered.

In the future we need to figure out a good API to properly support multi-entity forms and consumers shouldn't have to do anything like this.

Do we have a tracking issue for similar enhancements?

[ntsekouras]

Do we have a tracking issue for similar enhancements?

We have various issues for such enhancements, although I don't think we have a specific issue for this yet. The reason I'm not yet creating one is because the focus is elsewhere right now (extensibility) and I want to properly investigate what to suggest in that issue. It's probably something we need in core, but I need to explore other use cases for example to see what makes more sense to suggest. In core right now this is the only case we have (home/index template).