nested args in v0.2

[jardakotesovec]

I have been using nested argument like this in 0.1.1 and it worked fine.

Relay.createContainer(Images, {
    initialVariables: {
        selectedTags: {
            withTags: [],
            withoutTags: []
        }
    },
    fragments: {
        imageStore: () => Relay.QL`
            fragment on ImageStore {
                images(tagIds:$selectedTags) {
                    id, name
                }
            }
        `
    }
});

Relay embedded these args like this:

ImageStore{_images93dea933:images(tagIds:{withTags:["SW1hZ2VUYWc6MQ=="],withoutTags:[]}){..._19d515e66},id}

With version Relay 0.2 it creates reference to variables like this:

ImageStore{_imageshaoqfv:images(tagIds:$tagIds_0){..._1rdpi8q},id}'
variables: { tagIds_0: { withTags: [], withoutTags: [] } } }

I am pretty sure that I am passing variables object correctly to graphql function on server, but I get error from server

{"errors":[{"message":"Variable \"$tagIds_0\" is not defined by operation \"AdminImagesAll\"."}]}

Any idea whats going on? Name $tagIds_0 is clearly generated somehow by relay - so not sure how I could reflect that on server.

[josephsavona]

@jardakotesovec are you using the default network layer? Can you paste the full query that is sent to the server, along with the full set of variables? The snippet you included starts at an ImageStore fragment.

[josephsavona]

Note that tagIds_0 is being generated by Relay - passing input objects as variables allows the server to parse them appropriately (for example, it lets the server distinguish strings/enums).

[jardakotesovec]

Here is the whole payload from 0.2.0

{ query: 'query AdminImagesAll{imageStore{id,..._0wm5ea3}} fragment _0wm5ea3 on ImageStore{_imagesj00fxu:images(tagIds:$tagIds_0){edges{node{id,name},cursor},pageInfo{hasNextPage,hasPreviousPage}},id}',
  variables: { tagIds_0: { withTags: [], withoutTags: [] } } }

And server responds

{"errors":[{"message":"Variable \"$tagIds_0\" is not defined by operation \"AdminImagesAll\"."}]}

On server we are using latest graphql 0.4.2.

[jardakotesovec]

And yes, I am using default network layer.

[grydstedt]

Seeing same thing, unclear where this variable should be defined.

[yungsters]

@josephsavona Looks like the printed query is missing the type declaration for $tagIds_0.

[josephsavona]

@jardakotesovec @grydstedt this is now fixed on master.

[jardakotesovec]

Just updated to relay 0.2.1 and graphql 0.4.3 and request changed

{ query: 'query AdminImagesAll($tagIds_0:object){viewer{id,..._0xjmfqr}} fragment _0xjmfqr on Viewer{_images7lbrm8:images(first:50,tagIds:$tagIds_0){edges{node{id,name},cursor},pageInfo{hasNextPage,hasPreviousPage}},id}',
 variables: { tagIds_0: { withTags: [], withoutTags: [] } } }

And I get error from server:

{"errors":[{"message":"Unknown type \"object\"."}]}

Is that correct now and do I just need somehow add this object type? Thanks!

[jardakotesovec]

I can't reopen this issue.. should I open new one? Issue is still the same..

[jardakotesovec]

@josephsavona ping :-)

[josephsavona]

@jardakotesovec My bad, I didn't realize you couldn't reopen. Do you get this issue if you're running on master (for both react-relay and babel-relay-plugin)?

[jardakotesovec]

Thanks @josephsavona . You were right - babel-relay-plugin was behind, now the type is almost correct :-). At the moment I am using relay 0.2.1 and babel-relay-plugin 0.2.2.

It still does not handle correctly the non null type situation, my definitions is:

 new GraphQLNonNull(relationTypeEnum)

Therefore in request should be relationType!, which is not. Is that something that might be fixed already in master(s)?

Error I get:

{"errors":[{"message":"Variable \"$relationType_1\" of type \"relationType\" used in position expecting type \"relationType!\"."},...]}

Here is the request example:

{ query: 'query AdminImagesAll($tagIds_0:withAndWithoutTags,$relationType_1:relationType,$relationType_2:relationType,$relationType_3:relationType,$relationType_4:relationType,$relationType_5:relationType,$relationType_6:relationType){viewer{id,..._0xjmfqr}} fragment _3w7el36 on Image{_relatedImagesd7nirr:relatedImages(relationType:$relationType_1){id,fileWidth,fileHeight,filekey},_relatedImagesfa69fi:relatedImages(relationType:$relationType_2){id,fileWidth,fileHeight,filekey},_relatedImagescfvst1:relatedImages(relationType:$relationType_3){id,fileWidth,fileHeight,filekey},id} fragment _23315lv on Image{id,imageId,name,fileWidth,fileHeight,filekey,tags{id,name},..._3w7el36} fragment _1mly5s3 on ImageConnection{edges{node{id,..._23315lv},cursor}} fragment _5hj5jem on Viewer{imageTags{id,name,description,category},id} fragment _4hsj53x on Viewer{imageTags{id,name},id,..._5hj5jem} fragment _9vo6szn on Viewer{id} fragment _aqufpvv on Viewer{id} fragment _bg9nctn on Viewer{id} fragment _cjc0xfu on Viewer{id} fragment _dvitaj9 on Viewer{id} fragment _8wi40g5 on Viewer{imageTags{id,name,description,category,subcategory},_images8e8pyo:images(first:100,ids:[]){edges{node{id,imageId,tags{id},_relatedImagesd7nirr:relatedImages(relationType:$relationType_4){id},_relatedImagesfa69fi:relatedImages(relationType:$relationType_5){id},_relatedImagescfvst1:relatedImages(relationType:$relationType_6){id}},cursor},pageInfo{hasNextPage,hasPreviousPage}},id,..._9vo6szn,..._aqufpvv,..._bg9nctn,..._cjc0xfu,..._dvitaj9} fragment _77a8x6l on Viewer{id,..._8wi40g5} fragment _6s3xwri on Viewer{id,..._77a8x6l} fragment _e41m16e on Viewer{id,..._8wi40g5} fragment _0xjmfqr on Viewer{_images7lbrm8:images(first:50,tagIds:$tagIds_0){edges{node{id},cursor},pageInfo{hasNextPage,hasPreviousPage},..._1mly5s3},id,..._4hsj53x,..._6s3xwri,..._e41m16e}',
  variables: 
   { tagIds_0: { withTags: [], withoutTags: [] },
     relationType_1: 'PERSON',
     relationType_2: 'MOTIVE',
     relationType_3: 'SERIES',
     relationType_4: 'PERSON',
     relationType_5: 'MOTIVE',
     relationType_6: 'SERIES' } }

[josephsavona]

@jardakotesovec this is fixed in the PR - the printed type now accounts for arbitrarily nested lists/non-null annotations so that Relay will print $relationType_1:relationType! in your example. Working on getting this landed.

[josephsavona]

@jardakotesovec should be fixed on master now - let me know if this is still a problem!