你可以在没有Redux或Flux的情况下处理这个例子中的状态吗？如果是的话，你会怎么做呢？

Question

假设我有一个结构化的计时器，您可以一次查看和计时多个项目，并且在每个项目中，您可以查看和计时多个任务。由于这是一个计时器，因此您一次只能处理一个任务，因此一次只能处理一个项目。

由于这些限制，我将计时器分成三个独立的结构：

• TimerContainer（外部，保存并显示所有项目对象）
• ProjectContainer（中级，只包含一个项目，所有与项目相关的任务）
• TaskContainer（内部级别，只保存一个任务）。

只有TimerContainer和ProjectContainer保持状态。

---

TimerContainer：

TimerContainer对任务一无所知，但它执行初始API调用，以使用起始值为所有项目和任务设定种子。 TimerContainer还关注哪个项目当前正在跟踪时间（即，保存当前正在计时的项目的projectID值）。

---

ProjectContainer：

每个ProjectContainer都保存有关哪个任务当前正在计时（如果有）的信息，以及更新（在此处和通过API调用）在完成计时后每个任务所花费的时间。那时它通知TimerContainer它（该项目）不再是时间。

作为道具，TimerContainer为ProjectContainer提供当前跟踪项目ID，任务列表及其种子值以及各种项目信息。

---

这是我的问题：如果我更新TimerContainer的“当前跟踪ProjectID”值，它将触发所有ProjectContainers的重新呈现，包括刚刚更新其任务时间的那个。在我看来，除非我更新TimerContainer中为该特定任务保存的（现在是静态的）种子信息，否则它似乎会将其恢复为该任务的原始种子值。

如果我这样做，它会让我认为我必须使用相同的调用设置种子信息和当前跟踪projectID的状态，因为如果我按顺序执行它我不确定它是否会进入第二个状态改变请求。

如果这确实是一个问题（请随意说出来），我想它可以通过Redux或Flux来缓解，但鉴于已经建立的架构，我想看看是否有干净的方法来处理这个而不引入另一个图书馆第一。

---

最重要的是，没有其他图书馆，如何彻底解决这个问题？

---

---

更新：

似乎我对重新呈现受影响的状态初始化的方式感到困惑（即，它没有）。我在下面修改了Adam的例子来证明这一点（链接here）

在实现之后，我的问题的解决方案只是编写一个函数来处理每个ProjectContainers上的“当前跟踪ProjectID”prop值更改。

要实现的另一件事是shouldComponentUpdate函数（再次感谢），检查ProjectID是否与该ProjectContainer相关。

Answer 1

组件重新呈现不应该导致该组件失去其内部状态。这是一个example：子组件重新渲染，因为父级更改状态并传递子级新的道具，但子级保持其自己的内部状态。

就一般的设计选择而言，有一堆。以下是我要考虑的一些问题：

• 重新渲染是性能损失，因此请考虑为子组件自定义shouldComponentUpdate函数，以防止它们重新渲染
• 尽量使尽可能多的子组件无状态或纯净
• 考虑不在父组件中持久化“种子”值 - 不确定知道初始值是否有价值，但如果你只是将其传递给子组件，他们可以存储和增加

总的来说，听起来你可能会从商店中受益。能够将状态组织与功能分开可能会有所帮助。