假设我有一个结构化的计时器，以便您可以一次查看多个项目并对其进行计时，并且在每个项目中，您可以查看多个任务并对其进行计时。由于这是一个计时器，因此您一次只能为一个任务计时，因此一次只能为一个项目计时。
由于这些限制，我将计时器分为三个单独的结构：
- 计时器容器(外部，保存和显示所有项目对象)
- ProjectContainer(中级，只包含一个项目，所有任务都与该项目相关联) 任务
- 容器(内部级别，只保存一个任务)。
只有TimerContainer和ProjectContainer保持状态。
计时器容器：
TimerContainer对任务一无所知，但它会执行初始 API 调用，以使用起始值为所有项目和任务设定种子。TimerContainer还关注当前正在跟踪时间的项目(即保存当前正在计时的项目的 projectID 值)。
项目容器：
每个ProjectContainer都包含有关当前正在计时的任务(如果有)的信息，并在完成计时后更新(在此处和通过 API 调用)在每个任务上花费的时间。 此时，它会通知TimerContainer它(该项目)不再计时。
作为props，TimerContainer为ProjectContainer提供了当前跟踪的项目ID，任务列表及其种子值以及各种项目信息。
这是我的问题： 如果我更新TimerContainer的"当前跟踪 ProjectID"值，它将触发所有项目容器的重新渲染，包括刚刚更新其任务时间之一的项目容器。在我看来，这似乎将其恢复为该任务的原始种子值，除非我更新该特定任务的TimerContainer中保存的(现在是静态的)种子信息。
如果我这样做，它会让我认为我必须使用相同的调用为种子信息和当前跟踪的 projectID 设置状态，因为如果我按顺序执行此操作，我不确定它是否会到达第二个状态更改请求。
如果这确实是一个问题(请随意说其他)，我想Redux或Flux可以缓解它，但考虑到已经建立的架构，我想看看是否有干净的方法来处理这个问题，而无需先引入另一个库。
底线，如果没有另一个库，如何干净地解决这个问题？
更新：
似乎我对重新渲染影响状态初始化的方式感到困惑(即，它没有)。我在下面修改了亚当的例子来证明这一点 (链接在这里 )
在意识到这一点之后，我的问题的解决方案只是编写一个函数来处理每个项目容器上的"当前跟踪ProjectID"属性值更改。
要实现的另一件事是通过检查ProjectID是否与该ProjectContainer相关来实现shouldComponentUpdate函数(再次感谢)。
组件重新呈现不应导致该组件丢失其内部状态。下面是一个示例：子组件重新渲染，因为父组件更改状态并向子组件传递新 props，但子组件保留自己的内部状态。
就一般的设计选项而言，有一堆。以下是我会考虑的一些：
- 重新渲染会影响性能，因此请考虑自定义子组件的
shouldComponentUpdate函数，以防止它们重新呈现 - 尝试使尽可能多的子组件无状态或纯
- 考虑不要将"种子"值保留在父组件中 - 不确定知道初始值是否有价值，但如果您只是将其传递给子组件，它们可以存储并递增该值
不过总的来说，听起来您可能会从商店中受益。能够将状态组织与功能分开可能会有所帮助。