CacheStore rerender behaviour

[studioradiaal]

Hi, I am using rest-hooks in a ReactJS project, to visualize and control the status of an audio processing device. The device provides both a REST API and an async/websocket API. The websocket is used to receive notifications when parameters change, to avoid excessive polling. One of the main uses for the websocket is periodic updates of audio levels (every 40ms), to show on level meters in the UI.

I implemented a StreamManager, based on the description in the docs: https://resthooks.io/docs/api/Manager#data-stream. The level meters are always visible in the UI, so the StreamManager does controller.setResponse with the levels every 40ms. This causes the CacheStore to be updated at the same rate, which in turns rerenders EVERY component that uses the useLive hook, even if they use totally unrelated data. Some of those unneeded renders are quite expensive, resulting in a laggy UI.

So my question is: is there a way to prevent rerenders of components when their corresponding data has not changed? Ideally, I would want to implement this "globally" in the rest-hooks setup/configuration, or in the StreamManager, or on the endpoint of the fast-changing data, or ...
Preferably I don't want to change all slow-changing components/endpoints.

Hopefully you can give me some options or ideas to look at. Thanks.

(Note: I originally asked this question on the ask-rest-hooks Discord channel. At the request of the library maintainer, I started this discussion here).

[ntucker]

Thanks for posting here. A few questions on your use case:

• How coupled is the data from different streams? Is the 40ms stuff completely non-overlapping with other data?
• Do your websocket streams send data that you can also fetch (perhaps for first-load)?
• Is it fair to say the notifications is less frequent than 40ms? And the main pain point here is audio level updates?
• What version of React are you running?

These questions will help me better grasp what solutions may best suite this use case

[studioradiaal]

Thank for following up, here is some additional info.

Data from different streams is not really coupled. Many of the channels are device settings, which are changed infrequently (and independently from each other). If any of these settings is changed, that also causes a rerender of unrelated views, but that's fine because infrequent.
There is also, for example, a device temperature channel. This is set to 1 second intervals. I can still live with unnecessary rerenders every second (or choose a higher interval if needed).
Some settings, for example audio gain, are set using a rotary knob on the device. Those don't change often, but when they do, it's also fast: 50 à 100ms. For the views that currently use those settings, there's not really a problem, but if a solution were to be found, this would surely benefit from that solution.
But audio levels are always and continuously changing, and always shown in the UI. So yeah, the main pain point is the audio level updates.

To be more precise, the issue is most apparent when audio levels are shown in combination with the audio routing matrix (a 30 by 12 matrix that shows connected channels), which is too expensive to redraw every 40ms. Note that a changing audio level has no impact on the contents of the routing matrix, so the matrix data in the CacheStore doesn't change.

In general, every websocket stream has an identical GET endpoint. So when I need data in a react component, I use the useLive hook: under the hood, this will trigger a fetch on the GET endpoint (we set a low dataExpiryLength) to make sure we have the latest data for the first render, and the subscribe action will inform our backend that we want to receive updates for that specific piece of data.

Version info:

react@18.2.0
@rest-hooks/hooks@3.1.9
@rest-hooks/react@7.2.3
@rest-hooks/redux@6.3.2
@rest-hooks/rest@6.3.6

Hopefully this gives a better view on the use-case. I will gladly provide more details if needed.

[ntucker]

Preferably I don't want to change all slow-changing components/endpoints.

Totally understand this and we will be working towards potential solutions on this vein. However, since you mentioned the audio routing matrix is the most expensive re-render, I wonder if you have tried wrapping it in React.memo() and moving its data binding (useSuspense, useLive, useCache, etc) to a component above. This would make the expensive part not rerender. I do not suggest this be a long term solution, however I do wonder if this gives the biggest help in the performance issue described. If you have not tried this, I would love to hear about the results if it is not too much work. You could think of it as a workaround in the meantime.

Solution ideas

2 potential solutions come to mind for this, which may even potentially be used in conjunction.

useContextSelector

There exists https://github.com/dai-shi/use-context-selector which can prevent re-renders quite easily with existing code. However, it has a tradeoff which is why I have not simply used it - it doesn't work with some concurrent mode features of React 18, which makes it less ideal for some valuable performance use cases.

This would automatically prevent re-renders if any pieces don't changes. However, it would still do the (very fast - benchmarked at 1,000,000 operations a second - or 0.001 ms - on a slower end machine) checks for each data bind to make sure it remains referentially equal.

This would be published as a replacement library for /react with the same interfaces. Alternatively we could have usecontextselector be an optional peerDep and let the user configure which one they use.

Distinct CacheProviders for disjoint data streams

Another solution would be to setup more than one CacheProvider that could be configured to handle different endpoints. This might be configurable as a function that returns true if the endpoint should be handled. Then the main CacheProvider would just be a fallback for all other data types.

In this case you could setup the high frequency items in their own CacheProvider and this would not affect any other data bindings.

Thoughts?

Would love your thoughts on these ideas. Thanks for bringing this issue to my attention!

[studioradiaal]

I have tried your suggestion to wrap the expensive component in React.memo. Indeed, this prevents unnecessary rerenders, but it actually also prevents the desired rerenders. I'm not sure why exactly, maybe because of the referential equality concept in rest-hooks, or shallow comparison of objects. I quickly tried _.isEqual (and also a custom comparison function specific to this piece of data) in the arePropsEqual argument of React.memo, but that didn't help.

As a workaround, I have now created a second websocket, separate from rest-hooks, and the fast-changing component (audio level meters) subscribes to that websocket. This way, the rest-hooks cache is not involved, and no unnecessary rerenders are triggered. The main drawback is that the incoming data only exists locally in that component, not in central state. For now, audio levels are only used in one place, so that's fine. If the levels are needed in multiple components, some mechanisms are needed to share the data (context/cache), and manage the number of subscribed components (which, for the components that use rest-hooks, is done with a custom SubscriptionManager).

I think my current workaround, and the steps to improve it, fit within your second solution idea (Distinct CacheProviders for disjoint data streams). In my case, where data streams are indeed unrelated, this seems like the best solution. It would be similar to my current workaround, but with many of the benefits rest-hooks provides left intact.
Would this solution be transparent to the subscribing components? And would it affect subscription mechanisms (are managers/middlewares shared between the caches?).

At first sight, the other solution idea (useContextSelector) seems less appealing. I don't know it, but it seems to bring yet another complicated concept into the code, which I'd like to avoid at this point, since we are already far in development.