Add request configuration per List/Create/Show/Reference instance.

[Bnaya]

Is your feature request related to a problem? Please describe.
I'm using nestjsx/crud, an excellent library to create REST apis on top of typeorm and nestjs.
By default, relations/joins are not included in getOne/getMany responses,
And you need to specify in the url that you want to join them, means adding additional query params that are not configureable on the List Component level.
There is a way to configure eager relations, but then there is no way to turn them off.
And it's not only list, but for Edit and show.
I'm sure there's also relevant for other frameworks.

Describe the solution you'd like
A way to pass opaque configuration object, that will be set on the List, Show Edit, and references components, and will be transfer to the dataProvider on each action.
The data provider will figure out what more query params or additional actions to do by that config.

Describe alternatives you've considered

• Writing custom dataProvider and add configuration per resource
  works, but, if i want the same resource with a bit different behaviour (say on a reference i want a more lightweight version) i will need to trick my provider, and create "virtual" resource to get different configuration.
• duplicate resources on the server, with different default joins
  its very cumbersome

[fzaninotto]

This is not the path we've taken. React-admin sees the dataProvider as a REST-like API, and uses a resource-based grammar to communicate with it.

If you need to add eager relationships for all views, you'll have to do it on a per-resource basis in your dataProvider. If you need to add eager relationships for some views only, you'll get problems in react-admin, which shares a registry of the records fetched in all views.

So we won't add the ability to do what you ask within react-admin. But nothing forbids you from writing your own List or Edit component to accommodate this case by fetching exactly what you need.

[Bnaya]

You do support concept of configurable search, and sorting, that effects the query params,
That proposal is just to make it abit more generic to support additional arbitrary query params