Closed capaj closed 6 years ago
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 ;) )
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.
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.
Sorry for not responding sooner. The thing is I have a User
class. This class has Field
s 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}}
}
Having field that is mutating is rather not good idea.
why?
Could you describe in details your desired schema?
Currently if I return a class from
@Mutation()
and@Query()
and I want to have a field likepatch
( ) 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.