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

Question

The Flux pattern of having React components listen for updates to a central store is great, but seems to present an issue when you have numerous small, composable parts all on the same page requiring re-renders from a single store. On first inspection, it looks like the developer is required to tradeoff between two choices: creating a parent component which manages state and the rendering responsibilities of these smaller, repeatable components vs having each component manage its own resources, but hold a large number event handlers open (one for each repeated component).

To illustrate, my existing structure looks something like this:

• I have an EventList component that contains a list of (potentially hundreds of) Event components to render as children.
• The Event component includes an AuthenticatedImage as a child component when rendering.
• The AuthenticatedImage component listens to changes on the TokenStore and re-renders when an update occurs (a new token, re-render with that token).

TokenStore updates very rarely, but we definitely want to re-render all AuthenticatedImage components when this happens.

Here's the dilemma: If I have each AuthenticatedImage listen for changes to the TokenStore, Javascript starts complaining that we have a large number of open event handlers to the same event (that is, potentially hundreds of components all listening to the same event). In contrast, I could have the parent EventList component listen for updates to TokenStore, but then EventList starts owning the responsibilities of AuthenticatedImage, and AuthenticatedImage loses its portability.

Given these thoughts, what is the correct way to ensure that numerous instances of a component are re-rendered on a store change, without consuming exorbitant amounts of memory and angering the Javascript Gods, while ensuring code is kept clean and portable?

Answer 1

In flux-thinking, it sounds like your AuthenticatedImage should be a pure component = not having state (nor listeners) and only respond to props being passed down from parent. It is generally advised to try and keep state as high up in your component-hierarchy as possible.

Having the token-fetch in a component and in its state would make sense if only one of the images needs to respond to the new token. But this is not the case I understand.

By centralising token-fetching, AuthenticatedImage would still be quite portable. It only loses its responsibility to fetch the token, but this is probably a good idea anyway: there are evidently many components that need the same token, so centralising token fetching is a logical step. Especially if components other than your AuthenticatedImage respond to a token.

It also keeps your data stores and components aligned: centralised storing of token = centralised fetching of token. Putting it in the AuthenticatedImage component would make sense if you would also store each token separately with each image instance.

What you get in return is that any change in token-fetching logic needs to be processed only once, and not in each component-class that uses the token.