You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
REST endpoint doesn't replace path variables if supplied in HOC callback #197
import React, {Component} from 'react';
import {compose, withApollo, graphql} from 'react-apollo';
import gql from 'graphql-tag';
const C = class C extends Component {
render() {
return <div>{JSON.stringify(this.props.data)}</div>
}
};
const WC = compose(
withApollo,
graphql(gql`query ($emailAddress: String!) {
settings @rest(type: "Setting", path: "THIS_DOES_NOT_WORK/{args.emailAddress}", endpoint: "settings") {
settingId
}
}`, {
name : 'getData',
options: props => ({
variables: {
emailAddress: props.profileName
}
})
})
)(C);
export default class BrokenApollo extends Component {
render() {
return <div><WC profileName={'Blah'} /></div>
}
}
The URL requested by apollo-link-rest doesn't include the supplied value, and the following error is logged to the console:
Warning: RestLink caught an error while unpacking THIS_DOES_NOT_WORK/{args.emailAddress}|args.emailAddress This tends to happen if you forgot to pass a parameter needed for creating an @rest(path, or if RestLink was configured to deeply unpack a path parameter that wasn't provided. This message will only log once per detected instance. Trouble-shooting hint: check @rest(path: and the variables provided to this query.
After some further research, it appears that the following line is removing the values from the arguments object (it returns null) before it ends up at the pathBuilder. I may be incorrect, but it's as far as I can see:
(The @rest annotation doesn’t view the whole query generally, but actually just the node its attached to. And there’s an opportunity for the variable to be renamed on that node that it’s attached to so that you could pass the same outer variable to differently named inner parameters on each node. So you definitely need that! And that’s why this answer is actually relevant to the original ticket-filers @davewthompson — sorry I never caught that issue without the help from @MarvinNorway!)
I’ll leave this ticket open for now, but will eventually close it, as we finally have a solution, albeit 5 years later.
Activity
davewthompson commentedon Mar 14, 2019
Note that, in addition, if you use a standard Graphql query (remove the "@rest" segment) I can see the variables are sent in the variables header.
davewthompson commentedon Mar 14, 2019
After some further research, it appears that the following line is removing the values from the arguments object (it returns null) before it ends up at the pathBuilder. I may be incorrect, but it's as far as I can see:
davewthompson commentedon Mar 18, 2019
As a note to anyone else - this also breaks the in-memory cache, as the cache unique key is not properly defined and things get overwritten.
Unfortunately, the in-memory cache doesn't work properly either... apollographql/apollo-client#3452
fbartho commentedon Apr 15, 2019
I don't really use the GraphQL HOC pattern. Happy to support any pull-requests that will fix this functionality!
Sorry I didn't see this issue until now @davewthompson
MarvinNorway commentedon Feb 13, 2023
I'm seeing a similar issue:
https://stackoverflow.com/questions/75435714/apollo-client-ignoring-argument-for-gql-rest-query
Is this the same bug? Is there a workaround?
fbartho commentedon Feb 13, 2023
@MarvinNorway — Have you logged your
variables/ arguments to ensure that you’re not passing undefined toprojectId?I don’t think that StackOverflow is the same issue as what is described in this thread.
MarvinNorway commentedon Feb 13, 2023
@fbartho Yes, I verified that in the debugger in the browser. So it's really odd...
MarvinNorway commentedon Feb 17, 2023
@fbartho The problem was that the parameter has to be declared twice:
fbartho commentedon Feb 17, 2023
@MarvinNorway Ah! Yes, there’s complicated Apollo/GraphQL-internal reasons why that’s necessary!
(The
@restannotation doesn’t view the whole query generally, but actually just the node its attached to. And there’s an opportunity for the variable to be renamed on that node that it’s attached to so that you could pass the same outer variable to differently named inner parameters on each node. So you definitely need that! And that’s why this answer is actually relevant to the original ticket-filers @davewthompson — sorry I never caught that issue without the help from @MarvinNorway!)I’ll leave this ticket open for now, but will eventually close it, as we finally have a solution, albeit 5 years later.