Apollo GraphQl 存储派生数据

Question

一些背景：我正在开发一个 React JS 应用程序，它从数据库中读取地理点并以各种方式绘制/映射它们。有原始地图和图表直接显示来自数据库的数据，但也有图表和指标涉及对斜率图、图表下面积、直方图、欧几里得距离等点的分析。

我设置了一个 GraphQL 客户端，用于将数据提供给安装了 Apollo-Client 的 React 应用程序。这是 GraphQL 响应的示例：

{
  "data": {
    "Points": [
      {
        "pid": 13196,
        "x": 251.88491821289062,
        "y": 374.1650085449219
      },
      {
        "pid": 13197,
        "x": 257.6238708496094,
        "y": 374.17498779296875
      },
      {
        "pid": 13198,
        "x": 264.04315185546875,
        "y": 374.5350036621094
      },
      ...etc
    ]
  }
}

这太棒了！对于至少 2 个不同的数据视图来说，这是正确的形状，Apollo 客户端使用 InMemoryCache 为我缓存它，而我根本不需要 redux。

两难境地：我需要的一堆图涉及许多可重复使用的派生值（就像我可能在 2 个不同的视图中使用斜率值）。我应该将派生数据存储在哪里？

现在我已经把所有的计算都塞进了 React render() 方法中，但这似乎不是一个好主意。

选项：

1. 对派生数据使用 Redux，将所有计算放入 reducer，并以某种方式使其与 Apollo graphql 缓存中的内容保持同步。
2. 在服务器上进行派生（然后我可以缓存）并通过网络发送原始+派生。更多的网络流量，但更少的客户端计算。
3. 只要传入的 graphql 数据发生变化，就继续计算 render() 中的派生值。
4. 也许是我没有想到的……

Answer 1

1. Redux 可能是相当不错的选择 - 关注点/逻辑/数据的分离和良好的可测试性。
2. 这取决于最终的缓存命中/未命中率、额外资源/电源的成本 - 我会避免这种情况。
3. 渲染不是计算的最佳位置（还有其他生命周期方法）。组件可以使用自己的状态（或新的 getDerivedStateFromProps），但只能与子级共享。
4. 您可以使用react context api 或apollo-link-state 共享数据/方法。您可以尝试类似 observables/mobx 的解决方案。

我还会避免自动对数据更新进行所有可能的重新计算。通过组件/生命周期/上下文，您可以准备（缓存和共享）派生数据，当它真正被使用时。