如果打开 deferredMeasurementCache,由于 n 变成集合的大小,问题会呈指数级恶化。
如果您没有将 CellMeasurerCache 传递给 Grid 作为 deferredMeasurementCache 属性,则不能保证 Grid 正常工作。它有必要了解一些情况下的缓存。 (也许请查看this part of the docs 以确保您不会误解CellMeasurer 在用于计算行/列的宽度/高度时应该如何工作。)
话虽如此,您所描述的听起来就像一个错误,但我不确定它是否真的是。大体上是CellMeasurer measure method calling Grid.recomputeGridSize()同步触发forceUpdate()引起的(导致所有可见单元格重新渲染)。
起初我认为解决方案可能只是去抖动或排队 setState 操作。不幸的是,这只会将问题推开一点。可能性仍然存在。我不能去抖太久,否则我冒着Grid 向用户显示尺寸明显错误的单元格的风险。 (太大的去抖动甚至可能允许用户继续滚动到它前面,超过重新渲染。)也有可能图像会在真实应用程序中加载(延迟后)相距很远,打败我可能做的任何去抖动无论如何。
这里的问题是,每当一个单元格报告它具有不同的大小时,Grid 需要重新布局其他单元格(可能向上或向下移动它们)。在这个简单的例子中,这似乎是不必要的——因为所有图像最终都具有统一的宽度和高度。不过这并不典型。由于您已将 CellMeasurerCache 配置为测量高度,并且由于每列的高度会影响行的高度(以及所有其他列,如我上面链接到的文档中所述),Grid 必须重新- 每次报告更改时渲染所有单元格。
换句话说,如果您添加了更多行,并且将您的示例更改为更像这样:
const makeImages = (count=10, startIndex=0) => {
const width = 100;
const imagesArray = _.times(count, (index) => {
const height = 100 + Math.round(Math.random() * 200);
return {
key: startIndex+index,
src: `http://placehold.it/${width}x${height}/${((1<<24)*Math.random()|0).toString(16)}/fff?text=${startIndex+index}`,
}
});
return imagesArray;
};
那么也许更容易理解为什么对第 1 行第 1 列中的单元格进行更改可能会影响第 1 行中所有单元格的高度以及网格中所有单元格的位置。