情况

Question

情况

我有一个React / Redux应用程序，它在地图上显示标记，并根据当前缩放级别（similar to this example - 它们的接近程度将它们分组到群集中 - 我的应用程序与此示例略有不同，因为群集在地图将显示来自其子标记的特定数据，而不仅仅是子标记的总数。

我预计会经常添加新标记，应用会更新以实时显示新标记。

React组件结构如下所示：

<Map>
  <Cluster markerIds=[...] />
  ...
</Map>

因此，每次 a）将新标记添加到地图时，地图会重新渲染相应的群集， b）地图的缩放级别更改

我试图确定在Redux状态树中组织此数据的最佳方法。

选项1：简单方法

一种选择是保持状态树非常简单，让UI根据需要处理所有的聚类逻辑：

{
  markers: {
    1: { name: 'Bob', location: [-40.08, 37.62] },
    2: { name: 'Steve', location: [51.08, -25.62] },
    ...
  }
}

如果我以这种方式组织状态，则UI必须遍历每个标记并在每次缩放级别更改时重新计算可见群集。有了大量的标记，这可能会导致大量的重新计算，我预计用户在使用此应用程序时会进行大量的放大和缩小。

选项2：为每个缩放级别存储群集组

另一种选择是将群集组织保留在每个缩放级别的状态树中（例如1到19）：

{
  markers: {
    1: { name: 'Bob', location: [-40.08, 37.62] },
    2: { name: 'Steve', location: [51.08, -25.62] },
    ...
  },
  clustersByZoomLevel: {
    1: {
      clusters: [
        {
          clusterLocation: [22.59, -21.54],
          markers: [2, 11, 4]
        },
        ...
      ]
    },
    ...2-19: {...}
  }
}

在这种情况下，群集计算只会在新标记添加到地图时发生，并且只会在新标记上运行，而不是在整个集合上运行。放大或缩小不需要重新计算，因为群集组织已经存储在该州。

问题

那么，哪个选项更有意义？

一方面，我被迫保持简单，避免过早优化（即选择方案1）。

另一方面，我可以看到选项1很容易导致大量的重新计算频繁发生。选项2提供了一个状态树，可以更直接地转换为我的React组件结构。

您会建议哪个选项？为什么？他们的其他方法我不考虑可以更好地运作吗？

Answer 1

根据你的要求，两者都是可行的。

由于您确切问题的性质（取决于比例），我会说缓存层是完全可行的（只要纯数据集保留在那里）。

就我的团队运作的一系列抽象概念而言：如果它可以简单地导出，那么在变换器中进行，connect( transform, bind )( Widget );。

如果它不能轻易得出，那么缓存它就很有意义。

这方面的一个很好的例子是你可能有8000个原始产品结果，然后过滤滑块，它们对结果中的各种数据进行操作。
您将要保留一个filteredResults列表，以便您不必在运行中重新计算。

但是，更改视图的页码不应该要求重新运行所有这些昂贵的过滤器操作（即：在转换中），而只需从所有已经过滤的结果列表中选择切片的视图子集

它比你要求的更进一步，但我的另一个建议是“按UI组织”：小心你将公共数据从树的“页面”或“api”特定分支中旋转出来，并且将它们移到一个共同的地方，如果它们确实是常见的东西。

不得不在两个不同的地方改变一个物体，保持彼此同步会很痛苦。

{
  searchPage: { user },
  landingPage: { user },
  checkoutPage: { user }
}

匹配UI将会非常痛苦。

所以...转换你可以得到的东西，缓存你不能的东西，旋转更接近根的常用东西。

Redux状态树是否应该表示UI中数据的组织方式？

情况

选项1：简单方法

选项2：为每个缩放级别存储群集组

问题

1 个答案: