Add default Record representation

[fzaninotto]

Problem

React-admin forces developers to define a child <Field> for <ReferenceField> to represent the related record. This is cumbersome.

Solution

Add the ability to define a recordRepresentation at the <Resource> level, and let <ReferenceField>. Use that knowledge to render without a child.

-<ReferenceField source="user_id" reference="users">
-    <TextField source="name" />
-</ReferenceField>
+<ReferenceField source="user_id" reference="users" />

• Update <Resource> and ResourceDefinitionContext to carry the recordRepresentation
• Add a useGetRecordRepresentation hook
• Use recordRepresentation in <ReferenceField> and let it work without children
• Use recordRepresentation in <ReferenceOneField> and let it work without children
• Use recordRepresentation in <Edit> and <Show> page titles
• Use recordRepresentation in <SelectInput> and let it work without optionText when used in <ReferenceInput>
• Use recordRepresentation in <AutocompleteInput> and let it work without optionText when used in <ReferenceInput>
• Use recordRepresentation in <ReferenceInput> and let it work without children
• Update <ListGuesser>, <EditGuesser> and <ShowGuesser> to output child-less References
• Update tutorial
• Add doc (and rewrite the <SelectInput>, <AutocompleteInput>, and <ReferenceInput> docs in the process)
• Add tests

Closes #4899

[djhi]

This is so good! 💪

[djhi]

This is a breaking change for all translation packages

[fzaninotto]

No it's not. Existing translations will still work as before. We still pass the id, the recordRepresentation is passed in addition to other message args. The new translation takes advantage of it.

[djhi]

Isn't a good opportunity to avoid defaultProps? We could initialize those defaults when destructuring the props

[fzaninotto]

nice to have

[davidhenley]

This is great! Thank you!

[davidhenley]

@djhi @fzaninotto So if we want to validate the AutocompleteInput to be required can we do this?

<ReferenceInput source="territoryId" reference="territories" validate={[required()]} />

instead of

<ReferenceInput source="territoryId" reference="territories">
  <AutocompleteInput validate={[required()]}/>
</ReferenceInput>

Is there anything wrong with passing the props (label, validate, etc) down from ReferenceInput to AutocompleteInput? That would REALLY cut the code down!

[slax57]

@davidhenley currently you can't.
<ReferenceInput> default child is simply <AutocompleteInput />, so if you need to add other props, you have to declare the child explicitly.

I was about to answer that having the <AutocompleteInput> props also available on <ReferenceInput> might be confusing for the users, but actually they already share all the common input props. Only props that are not (yet) available on <ReferenceInput> are those specific to <AutocompleteInput>: debounce, filterToQuery, inputText, setFilter, shouldRenderSuggestions and TextFieldProps.

So yeah, actually, it's defendable, and does not look too complicated to do imho.
@djhi @fzaninotto what do you think?

[fzaninotto]

Personally, I never know if I have to pass the label or the validate prop to the ReferenceInput of its child. It's true that this part of the API is confusing.

But:

• some ReferenceInput do support a label (e.g. RefrenceArrayInput put its own label)
• Some ReferenceInput support the validation themselves, not their children (e.g. ReferenceArrayInput, again)

I'm not sure we can draw systematically pass props down.

I'll need to play with a Storybook that does all possibilities to understand the best decision to make.