Suggest only relevant DynamicPropSources

I think we should gather a list of things we think that should NEVER be available to map.

I think a clear example is all revision information, because thats' basically internal information. Or perhaps "author-only" information, if you will.

Pinged @lauriii to confirm 😊

Let's just omit revision_log_message. The two other examples have valid use cases i.e. displaying the author who had edited the node and when it was edited. I checked again and didn't see any other values we would have to omit.

Thanks!

I think @phenaproxima is well-positioned to review this given his recent involvement and his strong opinions on #3555300: Distinguish between prop source matchers (comprehensive, objective) and suggesters (ordered by importance, filtered by relevance: subjective) 👍

Oops!

The nature of the change here is straightforward but the code could maybe use a touch of a documentation and a small refactor for clarity.

Responded to @phenaproxima's feedback.

But more importantly: @lauriii promised me he'll check tomorrow for other cases, such as "Default translation" for a user, and "User status" for a user (or a revision user):

            "Revision user → User → Default translation" => 'ℹ︎␜entity:node:foo␝revision_uid␞␟entity␜␜entity:user␝default_langcode␞␟value',
            "Revision user → User → User status" => 'ℹ︎␜entity:node:foo␝revision_uid␞␟entity␜␜entity:user␝status␞␟value',

(Those are type: boolean matches. "Default translation" is a boolean field on ALL translatable content entity types. "User status" is to convey whether the user is active or blocked.)

I've added couple more fields that we should consider as irrelevant.

User Status field you may want to use if you're building a content template for the user entity – so let's not get rid of that.

Per

https://git.drupalcode.org/project/canvas/-/merge_requests/279#note_618627

created a core feature request: #3557353: Allow specifying additional metadata on Typed Data field definitions (or perhaps data definitions).

We could use the existing DataDefinition::setSetting(). Despite not being an interface method, core relies on it in many, many places.

#17: but only for actual settings for the given field type?

Implemented everything proposed by @lauriii 👍

Pivoting the implementation towards metadata-in-Typed-Data (asked by @lauriiii, explained by me on the MR why not feasible, disputed by @phenaproxima in #17, and that itself disputed by me in #18, for which I created a core feature request in #16) can happen in a follow-up issue.

This solves the problem at hand without presuming that we have sufficient data to bake in a formal API. I think we should first gain more real-world experience. IOW: hardcoded heuristics now, evolve to metadata-in-Typed Data later. With or without #3557353.

+1 RTBC. The changes make sense to me and it's wise that these subjective decisions are confined to PropSourceSuggester.

Cypress job #1 is a known failure, see #3539693-24: inputBehaviorsCommon mutates the passed props, breaking the rules of React. So went ahead and merged.