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

REST endpoint doesn't replace path variables if supplied in HOC callback #197

Open
davewthompson opened this issue Mar 14, 2019 · 9 comments

Comments

@davewthompson
Copy link

Given below code:

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.
@davewthompson
Copy link
Author

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
Copy link
Author

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:

 args = apollo_utilities_1.argumentsObjectFromField(field, variables);

@davewthompson
Copy link
Author

davewthompson commented 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
Copy link
Collaborator

fbartho commented 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
Copy link

MarvinNorway commented 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
Copy link
Collaborator

fbartho commented Feb 13, 2023

@MarvinNorway — Have you logged your variables / arguments to ensure that you’re not passing undefined to projectId?

I don’t think that StackOverflow is the same issue as what is described in this thread.

@MarvinNorway
Copy link

@fbartho Yes, I verified that in the debugger in the browser. So it's really odd...

@MarvinNorway
Copy link

MarvinNorway commented Feb 17, 2023

@fbartho The problem was that the parameter has to be declared twice:

export const getProjectCosts = gql`
    query GetProjectCosts($projectId: Int!) {
        ProjectCostList(projectId: $projectId) @rest(type: "ProjectCostList", path: "ProjectCosts/{args.projectId}") {

@fbartho
Copy link
Collaborator

fbartho commented Feb 17, 2023

@MarvinNorway Ah! Yes, there’s complicated Apollo/GraphQL-internal reasons why that’s necessary!

(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.

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

No branches or pull requests

3 participants