本文是小编为大家收集整理的关于Apollo GraphQl 存储衍生数据的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
某些上下文:我正在开发一个React JS应用程序，该应用程序从数据库中读取地理指向，并以各种方式绘制图形/映射它们.有一些原始的地图和图仅显示数据库的数据，但是也有一些图和指标涉及分析诸如斜率图，图形区域，直方图，欧几里得距离等点的分析.
.我设置了一个GraphQl客户端，可以将我的数据馈送到我的React应用程序中，并安装了Apollo-Client.这是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()方法中，但这似乎不是一个好主意.
选项:
- 将Redux用于派生数据，将所有计算放入还原器中，并以某种方式使其与Apollo GraphQl Cache中的内容同步.
- 执行服务器上的派生(然后我可以缓存)，然后在网络上发送两个RAW +.更多的网络流量，但客户端计算更少.
- 每当传入的GraphQl数据更改时，继续计算render()内部的派生值.
- 也许我没想到的东西...
推荐答案
- REDUX可能是很好的选择 - 关注/逻辑/数据和良好的可检验性.
- 这取决于最终的缓存命中/错过比率，其他资源/权力的成本 - 我会避免.
- 渲染不是用于计算的最佳位置(还有其他生命周期方法).组件可以使用自己的状态(或新的getDerivedStateStateStateStateStateStateStateStateStateStateState)，但仅与孩子共享.
- 您可以使用react context api或apollo-link-state共享数据/方法.您可以尝试可观察到的类似于MOBX的解决方案.
我还将避免在数据更新上自动所有可能的重计.使用组件/生命周期/上下文，您可以在真正使用时准备(缓存和共享)派生数据.
问题描述
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.
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
]
}
}
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.
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?
Right now I have all the calculations crammed into React render() methods but that's doesn't seem like a good idea.
Options:
- 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.
- 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.
- Continue calculating the derived values inside render() whenever the incoming graphql data changes.
- Maybe something I haven't thought of...
推荐答案
- Redux can be quite good option - separation of concerns/logics/data and good testability.
- It depends of eventual cache hit/miss ratio, costs of additional resources/power - I would avoid that.
- 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.
- 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.
更多相关问答
联系站长