什么是“撕裂"?在 React-Redux 的上下文中?

我是 Redux 的维护者，我写了那一段.

I'm a Redux maintainer, and I wrote that paragraph.

这是 React 团队的 Andrew Clark 特别提出的一个问题，认为这是与 React 即将推出的并发模式"一起使用时外部状态管理工具的潜在问题.

This is specifically a concern that has been raised by Andrew Clark from the React team as a potential issue with external state management tools when used with React's upcoming "Concurrent Mode".

在并发模式下，React 将能够暂停渲染通过树，并在稍后继续计算树的其余部分.

In Concurrent Mode, React will be able to pause a render pass through the tree, and resume calculating the rest of the tree later.

如果树中的组件正在读取一个外部值，并且该值在 React 的渲染暂停时发生了变化，那么树中的一些上层组件可能已经使用外部值 1 进行了渲染，而一些后面的组件可能会使用外部值 1 进行渲染可能使用外部值 2 进行渲染.这将导致渲染输出不一致，因为树的不同部分根据同一渲染通道中的不同值确定了它们的行为.这是撕裂".

If the components in the tree are reading an external value, and that value were to change while React's rendering is paused, then some of the upper components in the tree might have rendered using external value 1, and some of the later components might have rendered using external value 2. That would result in inconsistent render output, because different parts of the tree determined their behavior based on differing values in the same render pass. This is "tearing".

在 v6 中使用 createContext 背后的部分想法是，由于 React 确保给定的渲染通道在任何地方都使用相同的上下文值，因此不会有撕裂的机会.

Part of the idea behind using createContext for v6 was that since React ensures a given render pass uses the same context value everywhere, there would be no chance of tearing.

v6 实现确实有效，但在某些情况下并不像我们希望的那样高效.我们目前正在致力于提出一个不同的内部实现，该实现可以重新使用直接订阅代替.这确实意味着可能再次出现撕裂，但在这一点上，我们需要坐下来等待 React 团队完成并发模式的整合，然后我们才能花时间了解真正的问题所在.

The v6 implementation does work, but it's not as efficient in some cases as we'd hoped. We're currently working on coming up with a different internal implementation that goes back to using direct subscriptions instead. This does potentially mean that tearing is a possibility again, but at this point we need to sit back and wait for the React team to finish putting Concurrent Mode together before we can spend time seeing what the issues really are.