突变方法是否必须处于最高水平? [英] Are mutation methods required to be on the top level?

查看:88
本文介绍了突变方法是否必须处于最高水平?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所有文档和教程通常都显示简单的突变示例,如下所示:

All docs and tutorials usually show simple examples of mutations that look like this:

extend type Mutation {
  edit(postId: String): String
}

但是,这种方式edit方法必须在所有实体之间都是唯一的,在我看来,这不是一种非常健壮的书写方式.我想描述类似于我们描述查询的突变,如下所示:

But this way the edit method has to be unique across all entities, which to me seems like not a very robust way to write things. I would like to describe mutation similar to how we describe Queries, something like this:

type PostMutation {
  edit(postId: String): String
}

extend type Mutation {
  post: PostMutation
}

这似乎是一个有效的架构(它可以编译,并且可以在生成的graph-i-ql文档中看到它).但是我找不到让解析器使用此架构的方法.

This seems to be a valid schema (it compiles and I can see it reflected in the generated graph-i-ql docs). But I can't find a way to make resolvers work with this schema.

这是GraphQL支持的情况吗?

Is this a supported case for GraphQL?

推荐答案

这是可能,但通常不是一个好主意,因为:

It's possible but generally not a good idea because:

它违反了规范.来自第6.3.1节:

因为除顶级突变字段之外的其他字段的解析必须始终无副作用且是幂等的,所以执行顺序不得影响结果,因此服务器可以自由选择以任何顺序执行字段条目认为是最佳的.

Because the resolution of fields other than top‐level mutation fields must always be side effect‐free and idempotent, the execution order must not affect the result, and hence the server has the freedom to execute the field entries in whatever order it deems optimal.

换句话说,只有突变根类型上的字段才具有副作用,如CRUD操作.

In other words, only fields on the mutation root type should have side effects like CRUD operations.

从概念上讲,从根源上进行突变是有意义的.无论您执行的任何操作(喜欢帖子,验证电子邮件,提交订单等)都不依赖GraphQL在执行操作之前,请先解决其他字段.这与您实际查询数据时不同.例如,要获取帖子的评论,我们可能必须解析每个帖子的user字段,然后是posts字段,最后是comments字段.在每个级别",字段的内容取决于父字段解析为的值.突变通常不是这种情况.

Having the mutations at the root makes sense conceptually. Whatever action you're doing (liking a post, verifying an email, submitting an order, etc.) doesn't rely on GraphQL having to resolve additional fields before the action is taken. This is unlike when you're actually querying data. For example, to get comments on a post, we may have to resolve a user field, then a posts field and then finally the comments field for each post. At each "level", the field's contents are dependent on the value the parent field resolved to. This normally is not the case with mutations.

在后台,突变被顺序解决.这与并行发生的正常场分辨率相反.这意味着,例如,同时解析User类型的firstNamelastName.但是,如果您的操作类型为mutation,则一次将完全解析根字段.因此,在这样的查询中:

Under the hood, mutations are resolved sequentially. This is contrary to normal field resolution which happens in parallel. That means, for example, the firstName and lastName of a User type are resolved at the same time. However, if your operation type is mutation, the root fields will all be resolved one at a time. So in a query like this:

mutation SomeOperationName {
  createUser
  editUser
  deleteUser
}

每个突变都会一次出现,并按照它们在文档中出现的顺序进行.但是,这仅适用于根目录,并且仅在操作为mutation时适用,因此这三个字段将并行解析:

Each mutation will happen one at a time, in the order that they appear in the document. However, this only works for the root and only when the operation is a mutation, so these three fields will resolve in parallel:

mutation SomeOperationName {
  user {
    create
    edit
    delete
  }
}

尽管有上述要求,但如果您仍然想要这样做,这就是使用makeExecutableSchema时的方法,这是阿波罗在幕后使用的方法:

If you still want to do it, despite the above, this is how you do it when using makeExecutableSchema, which is what Apollo uses under the hood:

const resolvers = {
  Mutation: {
    post: () => ({}), // return an empty object,
  },
  PostMutation: {
    edit: () => editPost(),
  },
  // Other types here
}

您的架构将PostMutation定义为对象类型,因此GraphQL希望该字段返回一个对象.如果省略post的解析器,它将返回null,这意味着不会触发返回类型(PostMutation)的解析器.这也意味着,我们还可以编写:

Your schema defined PostMutation as an object type, so GraphQL is expecting that field to return an object. If you omit the resolver for post, it will return null, which means none of the resolvers for the returning type (PostMutation) will be fired. That also means, we can also write:

mutation {
  post
}

不执行任何操作,但仍然是有效的查询.这是避免这种架构结构的另一个原因.

which does nothing but is still a valid query. Which is yet another reason to avoid this sort of schema structure.

这篇关于突变方法是否必须处于最高水平?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆