React-admin: Allow a target prop in ReferenceField

[christiaanwesterbeek]

Is your feature request related to a problem? Please describe.
Consider

const CommentShow = props => (
    <Show {...props}>
        <SimpleShowLayout>
            <TextField source="id" />
            <ReferenceField source="post_id" reference="posts">
                <TextField source="title" />
            </ReferenceField>
            <TextField source="author.name" />
            <DateField source="created_at" />
            <TextField source="body" />
        </SimpleShowLayout>
    </Show>
);

In some database all primary keys are named id instead of [table_name]_id. I'm not saying having id as pk's is recommendable, but it is used quite often.

Describe the solution you'd like
How about allowing a target in ReferenceField? Just like ReferenceManyField is accepting both source and target.

const CommentShow = props => (
    <Show {...props}>
        <SimpleShowLayout>
            <TextField source="id" />
            <ReferenceField source="post_id" target="id" reference="posts">
                                             ^^^^^^^^^^^
                <TextField source="title" />
            </ReferenceField>
            <TextField source="author.name" />
            <DateField source="created_at" />
            <TextField source="body" />
        </SimpleShowLayout>
    </Show>
);

Describe alternatives you've considered
/

Additional context
/

[fzaninotto]

React-admin requires that the records it manipulates have an id attribute. If your backend doesn't provide one, it's the job of the dataProvider to do the translation.

Adding the target prop that you ask would imply leaking this "adapter" logic outside of the dataProvider. We won't do it.

[christiaanwesterbeek]

No problem. I hadn't considered translating in the dataProvider. Thanks for the suggestion.

Btw, you guys are awesome! I had this Datagrid with overly nested ReferenceManyFields and ReferenceFields. And it worked flawlessly. Really amazing what you are building! Again, 👏👏👏.

[fzaninotto]

Thanks a lot, we appreciate!

[aramando]

@fzaninotto @aramando I was looking into adding this functionality myself and submitting a PR - I'm glad I checked here first!

But with regard to the reason given here for not supporting a target prop on the ReferenceField component, why does this not also apply to the ReferenceManyField component, which does accept a target prop?

I also don't understand why the requirement for all records to be primarily-keyed by an id property precludes the use case of fetching a record that is related to the current record, just not by its primary key? What if one wishes to reference a related record by a foreign key that exists on the target, e.g. source="id" and target="user_id"?

[nickgrealy]

React-admin requires that the records it manipulates have an id attribute. If your backend doesn't provide one, it's the job of the dataProvider to do the translation.

Adding the target prop that you ask would imply leaking this "adapter" logic outside of the dataProvider. We won't do it.

Sorry about coming in late to the party - one question for @fzaninotto:

If you don't support joins on other properties (i.e. target), then why does ReferenceManyField have a target field? (Are there plans to remove it?)

https://github.com/marmelab/react-admin/blob/1e2e57554b45067a06c4e678b437213d269d25b0/packages/ra-ui-materialui/src/field/ReferenceManyField.tsx#L61-L74

[fzaninotto]

No, there are no plans to remove it from ReferenceManyField.

One of the reasons why ReferenceField requires that you use the id field is that we do an optim in datagrids having one ReferenceField per row to replace many getOne with one getMany... and this only works with the id field.

We don't have (or plan to have) such optims in ReferenceManyField.