React-admin: allow to pass arbitrary params to the dataprovider in `ReferenceInput`

[macrozone]

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

In a AutocompleteInput that is wrapped with ReferenceInput (or the Array versions), you might want to display additional information, e.g some other reference from the reference.

How this is done is up to the dataprovider. e.g. a graphql-data-provider would alter the query with some fragment.

Problem is that it seems that there are no props from ReferenceInput that get passed along to the data-provider (or expecially ra-data-graphql.

Describe the solution you'd like

if you add additional props to a ReferenceInput, they should get passed along to the data-provider and ra-data-graphql, so that the data-provider can use these props.

e.g. if you would want to show all roles that a user has in a selectInput:

<ReferenceInput 
  label="User"
  source="user"
  reference="User"
  options={{
     fragment: `
         id
         userName
         roles {
            id
            roleName
         }

     `
  }}
 <SelectInput
        disabled
        optionText={(user) => {
          return `${user.userName} (${user.roles.map(r => r.roleName)})`
        }}
      />
    </ReferenceInput>

Describe alternatives you've considered

We could also generalize the idea of specifying which fields the data provider should fetch in GetList or GetMany

Additional context
Add any other context or screenshots about the feature request here.

[macrozone]

one simple solution would be to pass rest to the dataprovider or add it to payload here:

https://github.com/marmelab/react-admin/blob/master/packages/ra-core/src/dataProvider/useDataProvider.ts#L422

[fzaninotto]

This is something we decided to exclude some time ago. You want to put dataProvider logic in the presentation layer, and this goes against the react-admin architecture.

You can implement that logic in the dataProvider directly, e.g. by using a different resource name. And if you need a very custom query to be made to your API, then add a custom method to your dataProvider, and write a custom component to use it.

[macrozone]

@fzaninotto you can easily argue, that defining which fields to fetch from a resource is indeed presentation layer concern. react-admin should inform dataproviders anyway which fields to fetch from a resource. Currently you tend to overfetch lists, which is another issue.

Adding another resource does not seem pratictal to me. ust because i decide to show the role names of a resource should not mean i have to invent a new virtual Resource UserWithRoleNames.

Custom components sounds more feasible, but still is a lot of work and needs duplication of exising react-admin code when only 1 line of code would need to be changed to allow fields to pass custom properties to data providers

[Dzhakhar]

This is something we decided to exclude some time ago. You want to put dataProvider logic in the presentation layer, and this goes against the react-admin architecture.

You can implement that logic in the dataProvider directly, e.g. by using a different resource name. And if you need a very custom query to be made to your API, then add a custom method to your dataProvider, and write a custom component to use it.

If you decided to exclude that functionality from react-admin, then you had to make sure that presentation layer is working properly. But there's bugs!

Please explain me, why this sample code is working properly

  <ReferenceInput label={"Specification"} perPage={20} source={"specificationName"}
                                    reference={ResourceNames.SPECIFICATIONS}>
                        <SelectInput optionText={"name"}/>
   </ReferenceInput>

while this code is showing the "Associated reference no longer appears to be available" error message.

  <ReferenceInput label={"Specification"} perPage={20} source={"specificationName"}
                                    reference={ResourceNames.SPECIFICATIONS}>
                        <SelectInput optionText={"name"} optionValue={"name"} />
   </ReferenceInput>

The only difference between above given examples - is the optionValue property passed to SelectInput. What's wrong with it? I don't want my SelectInput to use ID as a value...

Please help! Thank you in advance