Apollo GraphQL：类型策略中合并功能的用例？

我以前在Apollo’s community chat上问过这个问题，但由于在两周后仍未得到答复，因此我将其重新张贴在这里。

此问题与Apollo 3.0引入的新缓存有关。此更新弃用了本地查询，而支持“类型策略”（或“字段策略”），其中包括几种用于缓存的工具，例如可以为每种GraphQL类型定义的merge函数，以指定如何传入的数据应与缓存中的现有数据合并。

我想知道哪种用例更适合merge函数，而不是通过writeQuery或writeFragment编写预先计算的更新值。

假设我有一个包含对象的数组，该数组是另一种类型的属性。例如：

type Person {
  hobbies: [Hobby!]!
}

该应用程序允许我删除，添加和更新此数组中的元素。 hobbies是否应该使用merge函数？以前，我在局部突变解析器中编写了此逻辑，但已弃用了这些逻辑。我可以通过为每个解析器定义一个函数来轻松模仿旧的行为，该函数包含添加/删除/更新逻辑，并使用writeFragment存储结果。

我可以看到使用merge的好处，因为（我认为）它是较低的抽象层，但是可以用于传入的hobbies数组吗？据我所知，它的工作方式意味着我们必须通过传入的输入来推断出突变的类型。例如：

如果传入的数组少包含一个项目（或仅包含已删除的项目），则我们执行了删除操作，并且可以假定所有其他元素保持相同。
如果传入数组仅包含一个元素并且是新元素，则我们执行了添加操作，并将此元素合并到数组中
如果传入数组包含相同数量的元素（或只有一个更新的元素），则我们必须更新一个元素，并且现在必须找出要替换的元素（让我们假设由于实现原因，不可能直接更新单个Hobby，因为其他爱好也可能会受到影响，例如由于不重叠的时间限制）。

这似乎不像镜像旧方法那样优雅，在调用hobbies之前先计算writeFragment的新值。

使用merge有性能上的好处吗？使用hobbies时merge中现有和不受影响的项目是否保留在原位，而使用writeFragment时是否覆盖？假设传递给writeFragment的新计算数据包含一个数组，其中包含未修改元素的浅表副本。

非常感谢您为我解决此问题！