feature request: @MutationField and @QueryField

[Jiri Spac]

Currently if I return a class from @Mutation() and @Query() and I want to have a field like patch(

) on the class, this field is exposed on mutations and on queries as well. I'd like to avoid this-hence the new decorator. This could be achieved with a decorator config like @Field({mutationOnly: true}) or @Field({query: false}), but IMHO it's own decorator is more explicit way.

[Adam Pietrasiak]

I didnt understand your question. I'd appreciate if you take your time re-writing it :) If it'd be race called 'who is the fastests to submit issue', you'd win ;) )

[Jiri Spac]

basically:

@ObjectType()
class User {
  @Field() name: string

  @Field() price: number

  @Field() // here I would use the MutationField
  setSuperUser(): User {
    // do some actual mutation, not important for this demonstration
    return this
  }
}

@Schema()
class SuperSchema {
  @Mutation()
  createUser(name: string, price: number): User {
    const user = new User()
    return user
  }

  @Query()
  @Mutation()
  getUserById(id: number): User {
    return new User()
  }
}

const schema = compileSchema({ roots: [SuperSchema2] })
console.log('schema: ', printSchema(schema))

now the compiled schema looks like:

type Mutation {
  createUser(name: String!, price: Float!): User
 getUserById(id: Float!): User
}

type Query {
  getUserById(id: Float!): User
}

type User {
  name: String
  price: Float
  setSuperUser: User
}

Now anyone can just call this query:

{
 getUserById(1) { setSuperUser {name}}
}

but I would like them to only be able to call that via a mutation like

mutation {
 getUserById(1) { setSuperUser {name}}
}

currently they can call it like a query and mutation both.

[Adam Pietrasiak]

First of all, I think getUserById should be inside query, not inside mutation. Mutations are meant to mutate the state of the app.

Anyway, I see you're using

  @Query()
  @Mutation()
  getUserById(id: number): User {
    return new User()
  }

You're using both Mutation and Query decorator - that's the reason it's bresent in both. If you'd leave only @Mutation - it'll not be present in query anymore.

[Jiri Spac]

Sorry for not responding sooner. The thing is I have a User class. This class has Fields which are reading so they are gql queries, but it also has Field which are mutating the User instance.
That is why I have both Query and Mutation decorators there.
If I only put Query there, I can't call

mutation {
 getUserById(1) { setSuperUser {name}}
}

[Adam Pietrasiak]

Having field that is mutating is rather not good idea.

[Jiri Spac]

why?

[Adam Pietrasiak]

Could you describe in details your desired schema?