Skip to content

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

Open

Description

@davewthompson

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.

Activity

  1. davewthompson commented on Mar 14, 2019

    @davewthompson
    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.

  2. davewthompson commented on Mar 14, 2019

    @davewthompson
    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);
    
  3. davewthompson commented on Mar 18, 2019

    @davewthompson
    Author

    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

  4. fbartho commented on Apr 15, 2019

    @fbartho
    Collaborator

    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

  5. MarvinNorway commented on Feb 13, 2023

    @MarvinNorway

    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?

  6. fbartho commented on Feb 13, 2023

    @fbartho
    Collaborator

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

  7. MarvinNorway commented on Feb 13, 2023

    @MarvinNorway

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

  8. MarvinNorway commented on Feb 17, 2023

    @MarvinNorway

    @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}") {
    
  9. fbartho commented on Feb 17, 2023

    @fbartho
    Collaborator

    @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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions