robrichard / graphql-fields Goto Github PK

Maybe not what graphql-fields was intended for, but I'm using it client-side to do some custom automised caching logic on top of apollo.

package.json:

  "dependencies": {
    "graphql-fields": "^1.0.2",

.babelrc:

{
  "presets": [
    ["env", {
      "targets": {
        "browsers": ["last 2 versions"]
      },

=> IE11 and IE10 should be supported by jun 2018

node_modules/graphql-fields/index.js contains for instance an arrow function here:

return fields.reduce((o, ast) => {
            return flattenAST(ast, info, o);

...which gets inserted into bundle.js when using webpack and causes IE11 to break with a nice "Syntax error".

I don't know if you want to support this by compiling graqhql-fields to es5 but I just spent some time debugging this to figure out why a project didn't work in IE so I just thought I'd mention it ;)

In the latest version of graphql-js, fieldASTs was renamed to fieldNodes, which breaks graphql-fields.

I am looking to use this module in a TypeScript project and feel the usability would greatly improve with type definitions. Considering how small and self-contained the module is, I took a crack at just porting it to TypeScript. Let me know what you think, there should not be any breaking changes involved!

PR: #21

Hello here, is there any example that shows how to use this with buildSchema?

const projection = graphqlFields( fourth )

What I get from this is :

{
  key1 : {},
  key2 : {
   key2_1 : {},
   key2_2 : {}
 }
}

instead I want the empty objects as 1, since mongo doesn t like it. Like this :

{
  key1 : 1,
  key2 : {
   key2_1 : 1,
   key2_2 : 1
 }
}

So that I was trying to write a function to convert empty objects to 1s. But I think there should be a configuration to make this possible. Thanks.

    id
    assignedDate
    assignmentTakings(where: {submittedAt: {equals: null}, isSkipped: {not: true}}, skip: 1){
      id
      submittedAt
      isSkipped
    }
  }

result

{
  id: {},
  assignedDate: {},
  assignmentTakings: {
    id: {},
    submittedAt: {},
    isSkipped: {},
    __arguments: [
      {
        where: {
          kind: 'ObjectValue',
          value: { submittedAt: {}, isSkipped: { not: true } },
        },
      },
      { skip: { kind: 'IntValue', value: 1 } },
    ],
  },
}

as string

    id
    assignedDate
    assignmentTakings(where: {submittedAt: {equals: "null"}, isSkipped: {not: true}}, skip: 1){
      id
      submittedAt
      isSkipped
    }
  }

result

{
  id: {},
  assignedDate: {},
  assignmentTakings: {
    id: {},
    submittedAt: {},
    isSkipped: {},
    __arguments: [
      {
        where: {
          kind: 'ObjectValue',
          value: { submittedAt: { equals: 'null' }, isSkipped: { not: true } },
        },
      },
      { skip: { kind: 'IntValue', value: 1 } },
    ],
  },
}

Do you know of any way to convert these fields back to the Query Language?

For example, you say this will return:

{
  "profile": {
    "firstName": {},
    "lastName": {},
    "middleName": {}
  },
  "email": {},
  "id": {}

Instead of sending the fields to a REST server, I want to send them to another GraphQL server, so I'd want that in the "query language" format, like:

{ 
     profile { 
          firstName, 
          lastName, 
          middleName 
     }, 
     email, 
     id 
}

I would suggest adding an option to parse out the arguments passed on nested fields.

The example in the README is misleading, because as far as I can tell, a type cannot have a resolver function

I use this lib in my project and I want to move to graphql 15.

Can you set graphql as peer dependency and include 15?

I have a problem. Currently my company is incorporating this at the top level of a component during unit tests like so:
`...
import { GraphQLFieldsReturnType } from '../../../type-defs';

jest.mock('graphql-fields', () => ({
__esModule: true,
default: (arg: unknown): GraphQLFieldsReturnType => {
if (!arg) {
return null;
}
return {
savings: 'ALL',
someContent: { modules: 'Array', dynamicContent: 'Object' },
referralLink: 'http://xyz.com',
};
},
}));
describe('getPlansV1 resolvers', () => {
...`

My problem is that this makes testing very rigid and because it is at top level outside of component testing I would like to also incorporate other unit tests with various returns. How could I do that?

In the above code example we are bootstrapping your library to return nothing but I would also like to bootstrap it with return data that executes a happy path but it fails if I try to relocate this code from where it currently is to inside of a describe.

Keeping up the fight.

Variables that are used as arguments are not added as values when processArguments is set to true.

If i have a query like

query($first: Int!) {
  a {
    bs(first: $first) {
      bName
    }
}

with variables of

{ 
  "first" : 10
}

the arguments for b wont have any value :

 "__arguments": [
  {
    "first": {
      "kind": "Variable"
    }
  }
]

Where putting the vars into the query string directly does.

query {
  a {
    bs(first: 10) {
      bName
    }
}

=>

 "__arguments": [
  {
    "first": {
      "kind": "Variable",
     "value": 10
    }
  }
]

Hi, I just noticed an update was published and went to check the CHANGELOG and realized there wasn't one. Will you please add one so it's easier to track changes?

https://keepachangelog.com/en/1.0.0/

Issue

Default argument values defined in GraphQL Schema Language are not respected (when using the processArguments option).

Example

Schema:

type Bucket {
  id: ID,
  count: Int,
}
type Aggregations {
  income: [Bucket]
  geo(
    top: Float = 90,
    left: Float = -180,
    bottom: Float = -90,
    right: Float = 180
  ): [Bucket]
}
type Query {
  aggregate: Aggregations
}

Query:

{
  aggregate {
    geo {
      id
      count
    }
  }
}

Resolver:

const aggregate = (args, _, info) => {
  const requestedFields = graphqlFields(info, {}, { processArguments: true })
  // requestedFields.geo.__arguments is undefined
  ...
}

Followup issue to #22

When having variables there is no way to determine of what kind a variable actually is.

If we have a query like

query($first: Int!) {
  a {
    bs(first: $first) {
      bName
    }
}

with variables of

{
  first: 10
}

there is no telling that int is actually an integer in the result as the kind will always be Variable

 "__arguments": [
  {
    "first": {
      "kind": "Variable", // can we change this to have the kind Int?
     "value": 10
    }
  }
]

I think the current API for this package is limiting in several use cases:

• arguments
• supporting the same field queried multiple times via aliases
• fields queried on different inline fragment types (for interfaces and unions)

I'm opening up this issue to start a discussion on a new API to support these cases that is flexible enough to expand in the future. Please comment suggestions or any additional requirements that need to be supported.

Request example:

{
  field(arg:{ test: 1, test1: 2})
}

It does not return field argument value as object.

like { processArguments: true }, add a new option like {extensions: true}.

and will add __extenstions property

and maybe shall be another property like __leaf to tell if it reaches the end

Hey, your library is simple, small and efficient.
It would be great if you continue to maintain it. Let me know if you need any help with it.

Request example:

{
  field {
     subField(arg: 1)
     a:subField(arg: 2)
  }
}

This will return only second field subField with argument which value is 2.

A single input value on a field that should be a list is coerced to a list according to the Graphql spec.

Expected Type	Provided Value	Coerced Value
[Int]	1	[1]

So if you have a query:

foo(x: [Int])

And you are given

foo(x: 1)

you get

{
  "foo": {
    "__arguments": [
      {
        "x": {
          "kind": "IntValue",
          "value": 1
        }
      }
    ]
  }
}

but I expected

{
  "foo": {
    "__arguments": [
      {
        "x": {
          "kind": "ListValue",
          "value": [
            1
          ]
        }
      }
    ]
  }
}