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

[FR] Straightforward way of sending additional querystring parameters to the backend #7219

Closed
andreafdaf opened this issue Feb 9, 2022 · 6 comments

Comments

@andreafdaf
Copy link

Hi! I'm using RA and really loving it but there is something that make it "difficult" to integrate into existing backends (we are migrating a multi hundred endpoint application to RA).

Something we're missing is a straightforward possibility of sending custom query parameters from the components/hooks to the dataProvider and then from the dataProvider to the backend. What I would like to propose is a really simple mechanism to do it, like:

<List queryParams={{ populate: true }} {...props}>
<Create queryParams={{ template: 'sales' }} {...props}>
<Edit queryParams={{ reason: 'correction' }} {...props}>

And consequently (just one to make my point):

useGetList(
  'customers',
  {
    sort: ...
    filter: ...
    queryParams: { populate: true }
  }
)

And for example on ra-data-simple-rest:

getList: (resource, params) => { // inside params we have 'queryParams'
...
const query = {
    ...(params.queryParams ?? {}), // just a simple hack, it can be done in better ways
    sort: JSON.stringify([field, order]),
    range: JSON.stringify([rangeStart, rangeEnd]),
    filter: JSON.stringify(params.filter),
}

Creating custom resources, custom dataProviders, custom methods on the dataProvider... those all look far too complicated and cumbersome to achieve such a simple functionality.

I don't know if this is a breaking change or not, I'm proposing it as a standalone issue since I don't think it is backward incompatible.

Thanks for your time and for this library!

@WiXSL
Copy link
Contributor

WiXSL commented Feb 9, 2022

For current version of react-admin you have a solution here.

In the next mayor version, coming soon, you would be able to send extra parameters to any function of a dataProvider.

So, I'm closing this issue, since as an enhancement request it has already been address for version 4 of react-admin.

@WiXSL WiXSL closed this as completed Feb 9, 2022
@andreafdaf
Copy link
Author

Hi @WiXSL, thanks for this quick reply.

I don't think the v3 solution would work out since it relies on adding the parameter to filters, not as an autonomous querystring parameter. Anyway we are already building on v4 so to be already compatible once it comes out.

As for the v4 enhancement, are you talking about the 'meta' property?

It might work but looking for example at

it seems that there is no way to pass the meta property from the List component down to the dataProvider.

Am I missing something?

Thanks again!

BTW: if a subscription is necessary to go this deep into the conversation we'll happily purchase one (we already want to, so no problem at all to purchase it right now)

@WiXSL
Copy link
Contributor

WiXSL commented Feb 9, 2022

Yes, I'm talking about the meta parameter.
Check out the definition of useGetList you can pass as one of the params as meta argument

export const useGetList = <RecordType extends RaRecord = any>(

@djhi
Copy link
Collaborator

djhi commented Feb 9, 2022

it seems that there is no way to pass the meta property from the List component down to the dataProvider.

Not yet

@andreafdaf
Copy link
Author

@djhi I guess that my FR boils down to:

-> On v4, possibility of passing the meta property down from List, Create, Edit to the dataProvider.

BTW thanks for such a quick feedback, we just subscribed to the enterprise edition 🚀

@fzaninotto
Copy link
Member

For your information, this has been added to react-admin, and released in 4.2.0. See #7841 for details.

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

No branches or pull requests

4 participants