javascript - 当 React/Flux 中有几个小的、可重复的子组件时，如何管理组件渲染

Question

让 React 组件监听中央存储更新的 Flux 模式很棒，但是当您在同一页面上有许多小的可组合部分需要从单个存储重新渲染时，似乎会出现问题。乍一看，开发人员似乎需要在两种选择之间进行权衡:创建一个管理状态和这些较小的可重复组件的渲染职责的父组件，与让每个组件管理自己的资源，但持有大量事件处理程序打开(每个重复组件一个)。

为了说明这一点，我现有的结构如下所示:

• 我有一个 EventList 组件，其中包含要呈现为子组件的(可能有数百个)Event 组件列表。
• Event 组件在渲染时包含一个 AuthenticatedImage 作为子组件。
• AuthenticatedImage 组件监听 TokenStore 上的更改，并在发生更新时重新渲染(新 token ，使用该 token 重新渲染)。

TokenStore 很少更新，但我们绝对希望在发生这种情况时重新渲染所有 AuthenticatedImage 组件。

这是一个困境:如果我让每个 AuthenticatedImage 监听 TokenStore 的更改，Javascript 就会开始提示我们对同一事件有大量打开的事件处理程序(也就是说，可能有数百个组件都监听同一事件)。相反，我可以让父 EventList 组件监听 TokenStore 的更新，但随后 EventList 开始承担 AuthenticatedImage< 的职责 和 AuthenticatedImage 失去了可移植性。

考虑到这些想法，什么是正确的方法来确保在存储更改时重新渲染组件的大量实例，而不消耗过多的内存并激怒 Javascript 诸神，同时确保代码保持干净和可移植？

Answer 1

在flux-thinking中，听起来你的AuthenticatedImage应该是一个纯组件=没有状态(也没有监听器)并且只响应从父级传递下来的 Prop 。通常建议尝试将状态保持在组件层次结构中尽可能高的位置。

如果只有一个图像需要响应新 token ，则在组件及其状态中进行 token 获取是有意义的。但我理解的情况并非如此。

通过集中 token 获取，AuthenticatedImage 仍然非常可移植。它只是失去了获取 token 的责任，但这可能是一个好主意:显然有许多组件需要相同的 token ，因此集中 token 获取是一个合乎逻辑的步骤。特别是当 AuthenticatedImage 以外的组件响应 token 时。

它还可以使您的数据存储和组件保持一致: token 的集中存储= token 的集中获取。如果您还将每个 token 与每个图像实例分开存储，则将其放入 AuthenticatedImage 组件中是有意义的。

您得到的返回是 token 获取逻辑中的任何更改只需要处理一次，而不是在使用 token 的每个组件类中处理。