Change in order of hooks with patch 4.9.5

[mbmx10]

With the update 4.9.4 -> 4.9.5 we receive a lot of warnings like the following:

Warning: React has detected a change in the order of Hooks called by EntityTableContainer. This will lead to bugs and errors if not fixed. For more information, read the Rules of Hooks:

    Previous render            Next render
------------------------------------------------------
1.   useRef                     useRef
...
9.   useEffect                 useEffect
10. useState                  useRef

For that, we will pin to version 4.9.4 and observe this discussion.

[garronej]

Sorry about that!

[garronej]

@mbmx10,
Ok, it should be fixed in the latest release.
I'm very sorry to have broken your app with my patch!
I don't understand how it could have happen but I will investigate.

Thank you for reporting

[mbmx10]

Thanks for the swift resolution!

[mbmx10]

This discussion recently popped up when we removed a corresponding version pin.

We found, the reason for failing tests back then was, that a workaround on our side, to allow style-caching while using tss-react. This workaround used the internal call order of hooks.

[garronej]

hank you for providing the reproduction repository!

I have just released a new version of TSS featuring a significantly more advanced caching strategy. See in slow mode with the new version:

Screen.Recording.2024-07-26.at.17.59.06.mov

To take advantage of this update, you’ll need to switch to the modern API of TSS instead of using makeStyles. Don’t worry; the migration is straightforward and the new API offers substantial improvements over makeStyles.

P.S.: Just to clarify, I understand your example might be purely for demonstration purposes. However, using key={i} in your example will resolve the issue even without updating TSS. Previously, TSS’s cache was tied to the component’s lifecycle. The cache is now global and persists across component mounts. Nevertheless, components in a dynamic list should have stable keys to prevent the entire list from being flushed and re-created from scratch each time.

[garronej]

Hey @mbmx10 have you got time to check this out?

[mx-bernhard]

I understand your example might be purely for demonstration purposes

That is correct. We have big layout-container trees where each page has an entirely different tree and so all of these components get unmounted for the old page and mounted for the new page.

The cache is now global and persists across component mounts.

That is good to hear performance-wise (I inspected your PR in my browser, and it did perform well). What does this mean in terms of isolation between different parts of an application that might not even share the same React version? Can I still supply an emotion cache instance that is to be used by tss-react?

[garronej]

Hello @mbmx10,

What does this mean in terms of isolation between different parts of an application that might not even share the same React version?

There is no implication; everything remains isolated.

What's great about this update is that there is no trade-off; it's purely a performance gain with no gotchas. As far as you are concerned, TSS will behave exactly as it used to. The main change is that I can now skip the emotion calls when I detect that the styles have already been computed.

To be perfectly exact, there is one noticeable change for you: the function that you provide to TSS for computing the style for a given context is called much less often. However, this function is supposed to be pure, so not having it invoked repeatedly with the same parameters is what we want.

[mx-bernhard]

Sounds great. 👍