I am trying to send correct query on the https://api.sorare.com/sports/graphql/playground
Anyone maybe has an experience or knows how to read this mentioned doc?
Here is the example of what I am trying to retrieve, without success:
query GetNbaLeaderboard($slug: String!) {
nbaLeaderboard(slug: $slug) {
slug
}
}
Keep getting:
ClientError: must be defined: {"response":{"errors":[{"message":"must be defined","path":["variable","slug"],"extensions":{"code":"GRAPHQL_VALIDATIO
N_FAILED"}}],"data":null,"status":422,"headers":{}},"request":{"query":"\nquery GetNbaLeaderboard($slug: String!) {\n nbaLeaderboard(slug: $slug)
{\n slug\n }\n}\n","variables":{"slugs":["nba-gameweek-27-common-champion"]}}}
Ok so query is good but it also needs to have slug sent as a variable.
Related
I am performing a request for an individual post from Apollo Server / Express backend.
In the Apollo GraphQL sandbox, the query works and retrieves the correct post, however, the query has a red squiggle identifying an error which reads -
Variable "$getPostId" is never used in operation "Query".
The query is as follows -
query Query($getPostId: ID!) {
getPost(id:"20c9b3ac-afe6-4faa-a3f9-e00ef1b38ccf") {
title
author
id
}
}
The schema is as follows -
module.exports = gql`
type Post {
id: ID!
title: String!
author: String!
}
type Query {
getPosts: [Post]!
getPost(id: ID!): Post
}
...
`
The closest post which seems to address a similar problem I could find is here. However, I can't translate the resolution to my problem.
Why is the error showing (particularly when the query runs successfully)? What needs to be done to stop the error from showing?
Many thanks!
It sounds like
query Query($getPostId: ID!) {
getPost(id:"20c9b3ac-afe6-4faa-a3f9-e00ef1b38ccf") {
title
author
id
}
}
is supposed to be
query Query($getPostId: ID!) {
getPost(id: $getPostId) {
title
author
id
}
}
Or if your query is actually meant to hard-code the ID, then you want
query Query {
getPost(id:"20c9b3ac-afe6-4faa-a3f9-e00ef1b38ccf") {
title
author
id
}
}
GraphQL API has the following queries available:
query getUsers {
users {
id
name
}
}
query getUserAge($id: String!) {
user(id: $id) {
age
}
}
Is it somehow possible to combine both of these queries into one so we could get the users' names and ages in one go?
You can batch queries like this check here :
Just wrap one into another [and combine params if necessary]:
query getUsersAndUserAge($id: String!) {
users {
id
name
}
user(id: $id) {
age
}
}
You can use ready functions - https://stackoverflow.com/a/62727903/6124657
I have the following GraphQL query:
query workflowState($id: String!, $after: String!){
workflowState(id: $id) {
issues(after: $after) {
pageInfo {
hasNextPage,
endCursor
}
nodes {
id
title
labels{
nodes {
id,
name
}
}
}
}
}
}
The first time I run the query I do not want to pass after to the issues I would like to get all issues from the beginning.
When I parse the response, if hasNextPage is true I would like to call the query again and this time pass endCursor to after so I get the next set of paginated results.
I can successfully parse the response and make the second call but
how do I go about making the first call that does not have and after value?
I have tried passing an empty or non-existent UUID, and I get the error: Invalid input: after must be an UUID
This definition
query workflowState($id: String!, $after: String!){
... makes after variable required.
Solution:
Just remove '!' - exclamation mark:
query workflowState($id: String!, $after: String){
... and [when not required] don't pass 'after' variable - issues(after: $after) will get (will be evaluated to) undefined value. This way 'after' will work as an optional parameter.
I am quite new to GraphQL so I am struggling a little bit to understand how to write a proper Query on the front-end.
So, this is the Mutation I've on the server-side
type Mutation {
addTerminal(terminal: TerminalInput): Terminal
// other stuff not related
}
type Terminal {
terminalId: String!
merchantId: String
terminalDesignator: String
}
input TerminalInput {
terminalId: String!
merchantId: String
terminalDesignator: String
}
I believe it is using the right structure, but when I try to connect with the client-side im a bit confused.
This is the query I've on the front-end.
export const ADD_TERMINAL_MUTATION = () => (
mutation addTerminalMutation($terminalId: TerminalInput) {
addTerminal(terminal: { terminalId: $terminalId }) {
terminalId,
merchantId,
terminalDesignator,
}
}
);
and when I fire it to the server, I receive the following feedback:
Variable "$terminalId" of type "TerminalInput" used in position expecting type "String!".
So I changed to this:
addTerminal(terminal: { terminalId: "123" }) {
and got the error
Variable "$terminalId" is never used in operation "addTerminalMutation".
If I change to
mutation addTerminalMutation($terminalId: String!) {
It says that the TerminalId wasnt provided, but if I log it, it can be seen
So, what is the right way to write this ?
Thanks.
You need to change addTerminalMutation($terminalId: TerminalInput) to addTerminalMutation($terminalId: String!) to indicate the correct type.
First, the
Variable "$terminalId" is never used in operation "addTerminalMutation".
is caused by passing the variable in line
mutation addTerminalMutation($terminalId: TerminalInput)
and never referencing it later.
The problem in the second part seems that the terminalId parameter is not decomposed.
The parameter in the line
addTerminal(terminal: { terminalId: $terminalId })
is expected to be a String!.
You could do something like this:
addTerminal(input: $terminalId)
to pass in the whole terminal id object.
See this for further info:
https://blog.apollographql.com/designing-graphql-mutations-e09de826ed97
I'm using graphql-tag so i'm going to use that syntax.
Lets say I have this query:
const query = gql`
query user(id: String) {
user(id: $id) {
id
}
}
`
Whats the best patten to reuse that same query document node if on a different call I want the fields username and email in addition to id without having to rewrite the entire query again like:
const query = gql`
query user(id: String) {
user(id: $id) {
id
username
email
}
}
`
I'm using react-apollo on the frontend if that makes things anymore interesting.
Edit:
Just to clarify... something like this
const userIdFrag = gql`
fragment UserId on User {
id
}
`
const fullUserFrag = gql`
fragment FullUser on User {
id
username
email
}
`
const generateQuery = (documentNode) => {
return gql`
query user(id: String) {
user(id: $id) {
...documentNode
}
}
${documentNode}
`
}
const idQuery = generateQuery(userIdFrag);
const fullUserQuery = generateQuery(fullUserFrag);
(The above does work but give me errors from graphql in the console, which leads me to believe this is not something I should be doing)
Based on your comment the following should work:
const generateQuery = (documentNode, fragment) => {
return gql`
query user(id: String) {
user(id: $id) {
...${fragment}
}
}
${documentNode}
`
}
const idQuery = generateQuery(userIdFrag, 'UserId');
const fullUserQuery = generateQuery(fullUserFrag, 'FullUser');
Basically the fragment name used is the actual one that needs to be spread while the whole documentNode object is put at the end, after query's closing bracket
I am not the very expert on the topic, but here is what I have been able to find out. (if you see any mistakes in my assumptions, let me know).
I found this article that makes some good points against dynamically generating gql queries/mutations. It seems like you get some nice benefits with the static approach, although it's a bit more typing.
But, in case you do need to have dynamic fields, I haven't been able to find anything bad about using the #skip directive GraphQL provides. Here the docs ref.
For the case of using it in react-apollo they also have it in their docs.
So, your code can end up looking something like this:
const query = gql`
query user($id: String, $skipUserMeta: Boolean!) {
user(id: $id) {
id
username #skip(if: $skipUserMeta)
email #skip(if: $skipUserMeta)
}
}
`
You just pass the skipUserMeta as a variable alongside the id field.
NOTE: I actually found a video which talks about the exact same approach here