Apollo GraphQl存储派生数据 [英] Apollo GraphQl Storing derived data

查看:94
本文介绍了Apollo GraphQl存储派生数据的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

某些上下文:我正在开发一个React JS应用,该应用可以从数据库中读取地理点,并以各种方式对其进行图形化/映射.有一些原始图和图仅显示数据库中的数据,但也有一些图和度量涉及对点的分析,例如斜率图,图下面积,直方图,欧几里得距离等.

Some context: I'm developing a React JS app that reads geographic points out of a database and graphs/maps them in various ways. There are raw maps and plots that just show data straight from the database but there are also plots and metrics that involve analysis on the points like slope plot, area under graph, histograms, Euclidean distance etc.

我设置了一个GraphQL客户端,以便在安装了Apollo-Client的情况下向我的应用程序提供数据.这是GraphQL响应的示例:

I have a GraphQL client set up to feed me data to my react app with Apollo-Client installed. Here's a sample of the GraphQL response:

{
  "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
    ]
  }
}

太好了!对于至少两个不同的数据视图来说,这是正确的形状,Apollo客户端使用InMemoryCache为我缓存了这个形状,而我根本不需要redux.

This is great! This is the right shape for at least 2 different views on the data, Apollo client caches this for me using InMemoryCache and I haven't needed redux at all yet.

困境:我需要的许多图都涉及许多衍生值,这些值被重用(例如我可能会在2个不同的视图中使用斜率值).我应该在哪里存储我的派生数据?

Dilemma: A bunch of the plots I need involve a lot of derived values that get reused (like I might use the slope values in 2 different views). Where should I store my derived data?

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

Right now I have all the calculations crammed into React render() methods but that's doesn't seem like a good idea.

选项:

  1. 将Redux用于派生数据,将所有计算结果放入化简器中,并以某种方式使其与Apollo graphql缓存中的内容保持同步.
  2. 在服务器上进行派生(然后可以对其进行缓存),并通过网络发送两个原始+派生.更多的网络流量,但更少的客户端计算.
  3. 只要输入的graphql数据发生更改,就继续计算render()内部的派生值.
  4. 也许我没想到...
  1. Use Redux for the derived data, put all the calculations into reducers and somehow keep it synched up with what's in the Apollo graphql cache.
  2. Do the derivation on the server (which I can then cache) and send both raw + derived over the network. More network traffic but less client computation.
  3. Continue calculating the derived values inside render() whenever the incoming graphql data changes.
  4. Maybe something I haven't thought of...

推荐答案

  1. Redux可能是一个很好的选择-关注点/逻辑/数据分离和良好的可测试性.
  2. 这取决于最终的缓存命中率/未命中率,额外资源/功能的成本-我会避免这种情况.
  3. 渲染不是用于计算的最佳位置(还有其他生命周期方法).组件可以使用自己的状态(或新的getDerivedStateFromProps),但只能与子级共享.
  4. 您可以使用react context apiapollo-link-state共享数据/方法.您可以尝试可观察物/类似Mobx的解决方案.
  1. Redux can be quite good option - separation of concerns/logics/data and good testability.
  2. It depends of eventual cache hit/miss ratio, costs of additional resources/power - I would avoid that.
  3. Render is not optimal place (there're other lifecycle methods) for calculations. Component can use own state (or new getDerivedStateFromProps) but shared with children only.
  4. You can use react context api or apollo-link-state to share data/methods. You can try observables/mobx-like solutions.

我还将避免对数据更新自动进行所有可能的重新计算.借助组件/生命周期/上下文,您可以准备(缓存并共享)派生的数据,而这些数据将真正被使用.

I would also avoid automatic all possible recalculations on data updates. With components/lifecycles/contexts you can prepare (cache and share) derived data when it really will be used.

这篇关于Apollo GraphQl存储派生数据的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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