gatsby_gatsby graphql和有关类型定义的缺失但必要的解释

The error that appeared on my console was Cannot query field “Title” on type “strapiArticle”. I was working on Strapi at the time and the error seemed too foreign, too weird, too “GraphQLesque” when I first saw it, also it was too specific to my application to look for it on Google.

我的控制台上出现的错误是无法查询“ strapiArticle ” 类型的“ Title”字段 。 当时我正在使用Strapi，当我第一次看到它时，错误似乎太陌生，太奇怪，太“ GraphQLesque”，而且它对我的应用程序来说太具体了，无法在Google上查找。

When I started reading about GraphQL I thought it was an impressive technology that solved a very specific problem, the problem of querying exactly what you need from an established REST API data and reduce it to basically a “Query Language”. However this worked perfectly when all the data that has been queried does not have missing fields, if we have a REST API that returns [ { ‘lastname’: ‘Lovecraft’ } ] we cannot remove the ‘lastname’ or send it empty (e.g. {‘lastname’: ‘’}) whenever we feel like it, because GraphQL would exclude it from the query if not other entry has a value defined on this field, so if you have something like { user { lastname } } as your GraphQL query in your code and the ‘lastname’ field is empty in your REST API you would get a similar error message as the one you read in the first sentence.

当我开始阅读有关GraphQL的文章时，我认为这是一种令人印象深刻的技术，可以解决一个非常具体的问题，即从已建立的REST API数据中准确查询您所需要的问题，并将其简化为一种“查询语言”。 但是，当所有查询的数据都不缺少字段时，此方法非常有效，如果我们有一个返回[{'lastname'：'Lovecraft'}]的REST API，我们将无法删除'lastname'或将其发送为空(例如{'lastname'：''})，因为只要没有其他条目在此字段上定义了值，GraphQL就会将其从查询中排除，因此如果您将{user {lastname}}这样的内容作为GraphQL在您的代码中查询，并且REST API中的“姓氏”字段为空，您将得到与第一句中读取的类似的错误消息。

盖茨比-斯特拉皮问题 (The Gatsby-Strapi problem)

GatsbyJS is a recent technology that help us to solve an important problem, the problem of generating static websites based on CMS content, it solves this problem making use of GraphQL to query the CMS content data, as I explained at the begining of the first paragraph I was also working on Strapi at the time, Strapi is a very new CMS system that you can clone and modify in practically any way you need to, it has a very powerful content type manager that allows you to create any data model you can think of, some people often use Wordpress as well together with Gatsby experiencing exactly the same error. That means that the problem itself it is not a GraphQL issue nor a Strapi one and certainly not a Wordpress one either, the problem lies in human nature.

GatsbyJS是一项最新技术，可以帮助我们解决一个重要问题，即基于CMS内容生成静态网站的问题，它通过使用GraphQL查询CMS内容数据来解决此问题，正如我在第一段开头所解释的那样当时我还从事Strapi的开发工作，Strapi是一个非常新的CMS系统，您可以用几乎所需的任何方式对其进行克隆和修改，它具有非常强大的内容类型管理器，可让您创建任何您认为可以使用的数据模型当然，有些人经常与Gatsby一起使用Wordpress并遇到完全相同的错误。 这意味着问题本身不是GraphQL的问题，也不是Strapi的问题，当然也不是Wordpress的问题，问题在于人性。

Human nature is not seen as a problem on itself, it is something we need to deal with as software engineers (as we do it everyday), there is nothing wrong with Strapi and Wordpress they are just CMSs, and as CMSs they are subjected to change so if the business requires to make a field optional the user can choose not to fill it, that is where the Cannot query field “Title” on type “strapiArticle” error comes from, the user didn’t choose to fill the “title” field on the form we created on our Strapi CMS and the GraphQL query inside our Gatsby project will always look for it and will fail every time it doesn’t find it.

人性本身并不被视为问题，这是我们作为软件工程师需要处理的事情(就像我们每天都在做的那样)，对于Strapi和Wordpress来说，它们只是CMS，而作为CMS，则没有错进行更改，以便如果企业要求将字段设为可选，则用户可以选择不填充该字段 ，也就是说， “ strapiArticle ” 类型的“无法查询”字段“ Title”来自错误，因此用户没有选择填充“标题”我们在Strapi CMS上创建的表单上的“”字段以及Gatsby项目中的GraphQL查询将始终查找该字段，并且每次找不到它都会失败。

An interesting property of GraphQL is that the GraphQL query is not going to fail when at least one definition of the the field exists, for example if you have a list of users been returned from an API and at least one user has the “lastname” field defined with a value, GraphQL won’t fail for the other users that doesn’t have the field, that makes the problem even harder to detect early on. One of the cute solutions Gatsby suggests is to always create a dummy entry on Strapi or Wordpress so the GraphQL definitions won’t fail, how cute of them.

GraphQL的一个有趣特性是，当存在至少一个字段定义时，例如，如果您从API返回了用户列表，并且至少有一个用户具有“姓氏”，则GraphQL查询不会失败。使用值定义的字段，对于没有该字段的其他用户，GraphQL不会失败，这使得问题更难以早期发现。 Gatsby建议的一种可爱的解决方案是，始终在Strapi或Wordpress上创建一个虚拟条目，以使GraphQL定义不会失败，因为它们多么可爱。

类型定义作为Gatsby-Strapi问题的解决方案 (Type definitions as a solution to the Gatsby-Strapi problem)

Type definitions can be tricky and they can be misleading when you are not really sure about the problem you are solving, when I realized that the solution was only create the definition of the missing field I thought, “oh that’s easy”, but I was wrong, creating type definitions could lead to several ramifications, let’s see an example. What would be the type definition for the next GraphQL query if you want to solve the Cannot query field “Title” on type “strapiArticle” error?

当您不确定要解决的问题时，类型定义可能会很棘手，并且可能会误导我，当我意识到解决方案只是为缺少的字段创建定义时，我以为“哦，这很容易”，但是我错误，创建类型定义可能会导致若干后果，让我们来看一个示例。 如果要解决类型为“ strapiArticle ”错误的“无法查询”字段“标题”，下一个GraphQL查询的类型定义是什么？

If you are acquainted with type definitions you would probably be able to write a definition right away, however I was a GraphQL newbie and I just wanted to solve the Cannot query field “Title” on type “strapiArticle” error so after reading the definitions on the GraphQL documentation I tried the following:

如果您熟悉类型定义，则可能可以立即编写定义，但是我是GraphQL新手，我只是想解决类型“ strapiArticle ”错误的Cannot查询字段“ Title”，因此在阅读了以下内容的定义后GraphQL文档中，我尝试了以下操作：

That solved the error for that specific field problem, however, the fields “description”, “content” and the “author” section were optional too, the problem was solved but it would pop up again at any time if no dummy entries were created or even if they were created the error will appear again when the dummy entries were accidentally removed.

这就解决了该特定字段问题的错误，但是，“描述”，“内容”和“作者”部分也是可选的，此问题已解决，但如果未创建任何虚拟条目，它将随时弹出。甚至即使它们被创建，当虚拟条目被意外删除时，该错误也会再次出现。

So after hours of research and looking at different GraphQL type definitions on public GitHub repositories (The GraphQL documentation is not that explicit regarding type definitions) and after some trial and error I had came up with a way to define as a type the GraphQL query I’ve showed you at the beginning of the section.

因此，经过数小时的研究并在公共GitHub存储库上查看了不同的GraphQL类型定义(关于类型定义的GraphQL文档不是那么明确)，经过反复试验，我想出了一种方法来定义GraphQL查询作为类型I在本节的开头向您展示了。

The “author” field from the “strapiArticle” type definition was the hardest to figure out, many people don’t define it that way, actually they don’t define it at all, they usually create another definition called “strapiArticleAuthorArticle” and include the fields there, technically this is another way to do define the type and I don’t blame them, in the face of terror you take regretful decisions, but when I wrote this definition it seemed to me that this was a cleaner way to do it giving a sense of structure to the definition.

最难弄清楚“ strapiArticle”类型定义中的“ author”字段，很多人没有这样定义，实际上他们根本没有定义，他们通常创建另一个定义为“ strapiArticleAuthorArticle”并包括从技术上讲，这是定义类型的另一种方法，我不怪他们，面对恐怖，您会后悔地做出决定，但是当我编写此定义时，在我看来，这是一种更清洁的方法它给定义赋予了结构感。

The full implementation on Gatsby would be adding this piece of code to the “sourceNodes” function inside the “gatsby-node.js” file on the root of your project or plugin in the following fashion.

Gatsby的完整实现将以以下方式将这段代码添加到项目或插件根目录下“ gatsby-node.js”文件中的“ sourceNodes”函数中。

Defining your type definitions this way will assign a default “null” value to your properties that can be validated in the logic of your application avoiding to raise exceptions for optional new fields when building your static site.

通过这种方式定义类型定义将为属性分配一个默认的“空”值，该值可以在应用程序的逻辑中进行验证，从而避免在构建静态站点时引发可选新字段的异常。

结论 (Conclusions)

The error Cannot query field “Title” on type “strapiArticle” was solved at the end and also future errors with that specific type were avoided (at least the GraphQL ones), this problem teach us that for certain problems there are several solutions and the nature of the solution depends on the way the problem is affecting you. We could have fixed this issue adding a dummy entry to the “strapiArticle” but that will mean that for each new content type we added we would have to do the exact same thing, also if that dummy entry gets deleted by accident the error would pop up crashing the application unexpectedly. I am not telling you that this is not the right way to solve the problem, it actually is (at least for the Gatsby team), but if we wouldn’t have tried to look for a better solution we wouldn’t have learned how the types definitions work on Gatsby and probably this article wouldn’t have been written either. Try to always look for new ways to solve specific problems and never stop asking the question “Is this the best way to do this?”.

最后，解决了“ strapiArticle ” 类型上的错误“无法查询”字段“标题”，并且避免了将来使用该特定类型的错误(至少是GraphQL错误)，该问题告诉我们对于某些问题，有几种解决方案，并且解决方案的性质取决于问题影响您的方式。 我们可以解决此问题，并在“ trapiArticle ”中添加一个虚拟条目，但这意味着对于我们添加的每个新内容类型，我们都必须做完全相同的事情，如果该虚拟条目被意外删除，错误也会弹出导致应用程序意外崩溃。 我不是在告诉您这不是解决问题的正确方法，实际上(至少对于盖茨比团队而言)是正确的，但是如果我们不试图寻找更好的解决方案，我们就不会学习如何类型定义可以在Gatsby上使用，并且可能也不会写这篇文章。 尝试始终寻找解决特定问题的新方法，并且永不停止询问“这是否是解决问题的最佳方法？”的问题。