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

How to manage component rendering when there are several small, repeatable sub-components in React/Flux

本文关键字：组件何管理管理 Flux React 有几个更新时间：2023-09-26

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

为了说明，我现有的结构看起来像这样:

我有一个EventList组件，其中包含一个Event组件列表(可能有数百个)作为子组件渲染。
Event组件在渲染时包含AuthenticatedImage作为子组件。
AuthenticatedImage组件监听TokenStore上的变化，并在更新发生时重新渲染(一个新的令牌，用那个令牌重新渲染)。

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

这是一个困境:如果我让每个AuthenticatedImage侦听对TokenStore的更改，Javascript开始抱怨我们对同一个事件有大量开放的事件处理程序(也就是说，可能有数百个组件都侦听同一个事件)。相比之下，我可以让父EventList组件侦听TokenStore的更新，但随后EventList开始拥有AuthenticatedImage的责任，并且AuthenticatedImage失去其可移植性。

考虑到这些想法，在确保代码保持干净和可移植的同时，如何确保在存储更改时重新呈现组件的许多实例，而不消耗过多的内存和激怒Javascript之神?

在流体思维中，听起来你的AuthenticatedImage应该是一个纯组件=没有状态(也没有监听器)，只响应从父传递下来的道具。通常建议尽量将状态保持在组件层次结构的最上层。

如果只有一个图像需要响应新的令牌，那么在组件中并在其状态下进行令牌提取是有意义的。但据我所知并非如此。

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

它还使您的数据存储和组件对齐:令牌的集中存储=令牌的集中获取。如果您还将每个令牌分别存储在每个图像实例中，则将其放在AuthenticatedImage组件中是有意义的。

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