comprehensive param support for ra-data-graphql-simple adapter GET_MANY_REFERENCE requests

[maxschridde1494]

Support comprehensive pagination, sort and filter params for GET_MANY_REFERENCE requests. currently there is a gap using the ra-data-graphql-simple adapter when trying to use filter / sort / pagination props on the ReferenceManyField component.

[maxschridde1494]

The reason for this pull request is quite simple. I have a react-admin app running against a graphql api and decided to use the ra-data-graphql-simple adapter. Everything has worked perfectly except for the ReferenceManyField component. Currently, the ra-data-graphql-simple adapter does not support filtering, pagination and sorting params. i.e. code such as
<ReferenceManyField filter={{ type: 'CorporateDocument' }} reference="KycDocument" target="merchant.id" >
would issue a request like
{ operationName: "allKycDocuments", query: "query allKycDocuments($filter: KycDocumentFilter) ... , variables: { filter: {merchantId: "0af834d9-aa7a-423c-be16-33ea6a724006"} } }
when it should be
{ operationName: "allKycDocuments", query: "query allKycDocuments($filter: KycDocumentFilter) ... , variables: { filter: { merchantId: "0af834d9-aa7a-423c-be16-33ea6a724006", type: "IdentityDocument" } } }
I noticed discussion on this topic in closed issue #2571, specifically #2571 (comment). I piggy backed off @wmwart suggestion to use buildGetListVariables in the GET_MANY_REFERENCE case statement.

[maxschridde1494]

Also, due to the fact that I inserted an if statement in the buildGetListVariables for a simple check, make prettier made the diff of this function look way more complicated than it actually is. The changes were simple. I changed line buildVariables.js#103 to
let variables = { filter: {} }; if (params.filter) { variables.filter = Object.keys(params.filter).reduce((acc, key) => { ...
(i.e. only running the existing reducer that creates the filter object if params.filter is not null)

[wmwart]

@maxschridde1494, great news)
There is still a problem that I have not mentioned before. When using ReferenceManyField, for example:

<ReferenceManyField ... pagination={<Pagination />} >
    <Datagrid rowClick="show">
        ...
    </Datagrid>
</ReferenceManyField>

, and go to the page !== 1 , then click on row and return back to Datagrid. The page is reset to 1 :(
Very annoying. Is there such a problem with your corrections?

[fzaninotto]

As this is a new feature, please PR against the next branch rather than master

[djhi]

Awesome :) Thanks!

[maxschridde1494]

@fzaninotto updated to PR against next.

@wmwart re pagination, my changes do not fix that issue. I believe that is a different bug that has to do with the ReferenceManyField component itself, and not the dataProvider adapter.

[Kmaschta]

You'll have to keep only your commit on that branch.
To do so, you can run :

git checkout next && git pull origin next
git checkout patch-1
git rebase -i next ## In the prompt, only keep your commit and save
git push -f

[maxschridde1494]

@Kmaschta done.

[christiaanwesterbeek]

As this is a new feature, please PR against the next branch rather than master

This is unfortunate since it won't get into 2.x or am I wrong about that?

Related bug report: #3397

[maxschridde1494]

Any update on when this might get merged?

[fzaninotto]

3.0 is feature freeze - we're focusing on fixing bugs. I added that PR to the 3.1 release, scheduled in November.

By the way, this PR needs a rebase.

[maxschridde1494]

Sounds good.

Re:

By the way, this PR needs a rebase.

Will this be done on your end or is it something that I need to complete. I already completed the rebase @Kmaschta directed:

You'll have to keep only your commit on that branch.
To do so, you can run :

git checkout next && git pull origin next
git checkout patch-1
git rebase -i next ## In the prompt, only keep your commit and save
git push -f

[fzaninotto]

It is something you'll have to do, maybe using the "resolve conflicts" button lower in the page.

[maxschridde1494]

When is the scheduled release for v3.1?