从GraphQL网关到TinaCMS
包重组
在我们试用GraphQL API及其与TinaCMS的工作方式时，很明显这是我们希望为TinaCMS用户开辟的主要路径。我们将把tina-graphql-gateway API移入tinacms包中，以反映其在TinaCMS工作流程中的更核心角色。其他后端集成仍然可以通过新的@tinacms/toolkit包进行构建。您可以在这里阅读更多关于这些更改的详细信息。
tinacms正在吸收tina-graphql-gateway
因此，升级到新的改进的GraphQL体验将需要您迁移到tinacms@0.50.0并完全移除tina-graphql-gateway包。
tina-graphql-gateway-cli现在是@tinacms/cli
注意：defineSchemaAPI也已更改。请继续阅读以了解如何升级
tina-gql命令行命令现在是tinacms
新的defineSchema API
我们将依赖于TinaCMS中类型定义的更原始概念，并因此对模式定义方式引入一些重大更改。
集合现在接受fields或templates属性
您现在可以为您的集合提供fields而不是templates，这样做将导致更直接的模式定义：
为什么？
以前，一个集合可以定义多个模板，这一特性引入的模糊性意味着您的文档需要一个_template字段，以便我们知道它们属于哪个模板。这也意味着在graphql中必须对查询进行消歧：
今后，如果您在集合上使用fields，您可以省略_template键并简化您的查询：
type更改
类型看起来会有些不同，旨在反映它们可以代表的最低形式。今后，ui字段将代表您可能期望的UI部分。对于博客文章的“描述”字段，您可以这样定义：
默认情况下，string将使用text字段，但您可以通过指定component来更改：
大多数情况下，UI属性会添加到字段中，并遵循TinaCMS核心字段插件的现有功能。但没有什么能阻止您提供自己的组件——只需确保在前端将它们注册到CMS对象中：
注册您的myMapField到TinaCMS：
一个重要的注意事项
defineSchema API中的每个属性都必须是可序列化的。这意味着函数将不起作用。例如，无法在此级别定义validate或parse函数。但是，您可以使用formifyCallback API来访问TinaCMS表单，或者通过指定您选择的插件来提供自己的逻辑：
然后在注册插件时，在这里提供您的自定义逻辑：
为什么？
实际上，这对后端没有任何影响，因此我们将其作为一个摩擦点移除。相反，type是真正定义字段_形状_的，而ui可以用于自定义字段UI的外观和行为。
每个type都可以是一个列表
以前，我们有一个list字段，允许您提供一个field属性。相反，_每个_原始类型都可以表示为一个列表：
此外，可枚举列表和选择项是从options属性推断出来的。以下示例由一个select字段表示：
而这个是一个checkbox字段
引入object类型
TinaCMS目前以两种方式表示对象的概念：group（和group-list），它是字段的统一集合；以及blocks，它是多态集合。今后，我们将引入一种更全面的类型，它涵盖了group和blocks的行为，并且由于_每个_字段都可以是一个list，这也使得group-list变得多余。
注意：我们之前假设blocks的使用_总是_作为一个数组。为了兼容性，我们将保留这种假设，但object将允许非数组的多态对象。
定义object类型
object类型接受fields或templates属性（就像collections定义一样）。如果您提供fields，您将得到一个本质上是group的项目。如果您说list: true，您将得到以前的group-list定义。
同样，如果您提供一个templates字段并且list: true，您将获得与blocks相同的API。然而，您也可以说list: false（或完全省略它），您将拥有一个不是数组的多态对象。
注意 -type: object与templates: []和list: false尚不支持表单生成。您可以在API中使用它，但无法编辑该字段。
这与当前的blocks定义相同：
这是一个group的例子：
引入dataJSON字段
您现在可以请求dataJSON作为整个数据对象的单个查询键。这对于像主题文件这样繁琐的查询非常有用，因为在结果中包含每个项目是很麻烦的。
注意，目前此功能没有typescript帮助
请记住，dataJSON不会跨多个文档解析。相反，它将返回引用的外键：
列表查询将遵循GraphQL连接规范
以前，列表会返回一个简单的项目数组：
这将导致：
在新的API中，您需要通过edges和nodes：
为什么？
GraphQL连接规范打开了一个更具未来性的结构，允许我们将更多信息放入_连接_本身，比如返回了多少结果，以及如何请求下一页数据。
阅读详细解释以了解连接规范如何提供更丰富的功能集。
注意：列表查询仍然不支持排序和过滤。
_body不再默认包含
相反，可以将isBody布尔值添加到任何string字段
为什么？
由于markdown文件有一个隐含的“主体”，我们自动填充了一个代表markdown文件主体的字段。这并不那么有用，而且有点烦人。相反，只需将isBody附加到您希望代表markdown“主体”的字段上：
这将导致一个名为My Body的表单字段被保存到您的markdown文件的主体中（如果您使用的是markdown）：
其他更改
引用现在指向多个集合
不再是一个collection属性，您现在必须定义一个collections字段，这是一个数组：
多态对象（以前的_blocks_）上的template字段现在是_template
旧API：
新API：
data __typename值已更改
它们现在包括适当的命名空间以防止命名冲突，并且不再需要_Doc_Data后缀。所有生成的__typename属性将略有不同。我们没有完全命名空间字段，因此无法保证不会发生冲突。在通过块查询和过滤时，这里的痛苦可能最为明显。这确保了此类型在未来的稳定性
未定义的列表字段将返回null
以前未在文档中定义的可列字段被视为一个空数组。今后，API响应将导致null而不是[]：
响应将是categories: []。如果您完全省略该字段：
响应将是categories: null。以前这将是[]，这是不正确的。