问题:当我呈现了~>20个组件时，React应用程序中的缩放特性会变慢到爬行。我的应用程序需要能够支持1000秒的渲染组件缩放。
缩放的当前实现:
目前，在我的应用程序中，我有一个具有缩放特性的父组件，它监听onwheel事件，并使用useste钩子更新zoomFactor变量。
此父组件的每个子组件都使用UseContext访问ZoomFactor，因此每当ZoomFactor更改时，子组件都会接收到此更改，并通过将其原始的Offsetx和Widty乘以更新后的ZoomFactor来更新其相关维度（在我的示例中是Offsetx和Widty，从而得到ZoomAdjustedOffsetx和
最后，这些缩放调整后的值包含在styles对象中:
const styles = {
transform: 'translateX(' + zoomAdjustedOffsetX + 'px)',
width: zoomAdjustedWidth + 'px',
}
它内联地传递给返回的组件。
我很确定性能问题源于这样一个事实:在缩放的每一步中，我都要重新呈现所有这些组件。我不需要重新呈现组件，我只需要在onWheel事件期间更新它们的CSS的两个属性，以准确地反映更新后的ZoomFactor。
因此，我目前对于如何修复性能问题的想法是:
>
在父组件中维护一个对象的引用，该对象将每个子组件的id映射到相应子组件的ref。
在onwheel事件期间，遍历所述映射，并使用新的ZoomFactor“手动”更新每个子组件的CSS。
我知道这不是正确的“反应方式”，但我想不出另一种方式来实现我的目标，即通过更新每个组件的CSS来实现缩放效果，而不是将我的应用程序拖慢到重新呈现所有内容的爬行。
我的问题:这种方法会带来性能上的好处吗？您能想到在onwheel事件期间操作1000个组件的CSS以实现“缩放”效果的其他策略吗？
更新宽度是这里的杀手锏。唯一真正快速更新的CSS属性是transform和opacity。使用transform:scale可以实现您想要的目标吗？
下一个要看的是去声响事件。onwheel每帧激发多次，但您只需每帧呈现一次。
在CSS中设置will-change和contain:layout可能也会带来一些小好处。
如果在所有这些之后它仍然很慢，您可能会考虑避免React更新，就像您提到的那样。你可以用React-spring来实现这一点，而不是使用自己的系统。
