Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for meta parameter in queries #7116

Merged
merged 2 commits into from
Jan 21, 2022
Merged

Add support for meta parameter in queries #7116

merged 2 commits into from
Jan 21, 2022

Conversation

fzaninotto
Copy link
Member

@fzaninotto fzaninotto commented Jan 20, 2022

Problem

The Data Provider vocabulary is restrictive. Sometimes, developers need to tweak the request for a particular request, by passing special parameters. They need to multiply resources and add code to the dataProvider because they can't pass additional parameters.

Solution

All Data Provider methods now accept a meta parameter. React-admin doesn't set this parameter by default in its queries, but it's a good way to pass special arguments or metadata to an API call.

const { data, isLoading, error } = useGetOne(
    'books',
    { id, meta: { _embed: 'authors' } },
);

It's up to the Data Provider to interpret this parameter.

@fzaninotto fzaninotto added the RFR Ready For Review label Jan 20, 2022
@fzaninotto fzaninotto added this to the 4.0.0-alpha.2 milestone Jan 20, 2022
@fzaninotto fzaninotto mentioned this pull request Jan 20, 2022
docs/Actions.md Show resolved Hide resolved
Copy link
Collaborator

@djhi djhi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Are we going to add support for a meta prop on our components as well?

@alanpoulain
Copy link
Contributor

alanpoulain commented Jan 20, 2022

It reminds me of something 😅 (I know it's hard to maintain this framework, don't worry! I appreciate your work).
#4834
Edit: OK it's not exactly the same thing, but I still think my reasoning applies: responses need also a meta parameter (data providers need to be able to "transmit" some information to the components using them).

@fzaninotto
Copy link
Member Author

fzaninotto commented Jan 20, 2022

It reminds me of something 😅 (I know it's hard to maintain this framework, don't worry! I appreciate your work). #4834 Edit: OK it's not exactly the same thing, but I still think my reasoning applies: responses need also a meta parameter (data providers need to be able to "transmit" some information to the components using them).

We're adding meta to the request in this PR, not in the response.

As for the response, we're currently working on adding support for partial pagination (i.e. list responses with no total but with a hasNextPage boolean) rather than a generic meta.

@alanpoulain
Copy link
Contributor

We're adding meta to the request in this PR, not in the response.

As for the response, we're currently working on adding support for partial pagination (i.e. list responses with no total but with a hasNextPage boolean) rather than a generic meta.

OK that's nicer to have a well-defined API for the partial pagination, but I still think having a meta parameter in the response is needed, especially for the metadata-oriented API (JSON-LD/Hydra) or when custom information are sent in headers.
React-admin cannot think of all the use cases (partial pagination was one of them).

@fzaninotto
Copy link
Member Author

OK that's nicer to have a well-defined API for the partial pagination, but I still think having a meta parameter in the response is needed, especially for the metadata-oriented API (JSON-LD/Hydra) or when custom information are sent in headers. React-admin cannot think of all the use cases (partial pagination was one of them).

With the new Query API (using react-query), if you ever need to call your data provider with custom params and read the full response, it's super easy. I don't think we should handle that in core.

@alanpoulain
Copy link
Contributor

With the new Query API (using react-query), if you ever need to call your data provider with custom params and read the full response, it's super easy. I don't think we should handle that in core.

That's good to know, it will be feasible to add custom behavior to components using data providers then, but I still think that it would be great if data are analyzed and returned with a special meta parameter by data providers, since it's their responsibility.
Anyway maybe more use cases will appear in the future and maybe you will reconsider it at this time.

@RWOverdijk
Copy link
Contributor

Nice! Are we going to add support for a meta prop on our components as well?

I am curious about this as well. Our API only returns relations when asked (_embed) since we're using ra-data-json-server which uses _embed for that as well because that's the spec. Without that we can't use (and more specifically ReferenceArrayInput) and need a custom form.

@fzaninotto
Copy link
Member Author

You don't need an embed to use ReferenceArrayInput. ReferenceArrayInput fetches the related data itself.

@RWOverdijk
Copy link
Contributor

@fzaninotto It doesn't seem to do that for edit. I mean, it fetches the options, sure. But it doesn't change anything to the getOne of the that tells the api to include the currently linked ids.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFR Ready For Review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants