Warning in tests/MainThreadRpcDriver: useLayoutEffect does nothing on the server

This warning shows up in tests on master branch (see e.g. here) and anytime that MainThreadRpcDriver is used:

Warning: useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. To avoid this, useLayoutEffect should only be used in components that render exclusively on the client. See https://fb.me/react-uselayouteffect-ssr for common fixes.

It looks like this is related to Material-UI, and the warning appears when server-side rendering is done in an environment where a DOM is detected (like when everything is done in the main thread, which we do in out tests). Further reference: https://github.com/mui-org/material-ui/issues/15798

[cmdcolin]

but you are saying it could be triggered by other portions of the codebase as well…

if you comment out this section in config/jest/console.js

then you will get a ton of useLayoutEffect warnings when running tests

this will match also what is seen when using MainThreadRpc in the app since tests use MainThreadRpc

diff --git a/config/jest/console.js b/config/jest/console.js
index b2a35b0ee..c2079a4c1 100644
--- a/config/jest/console.js
+++ b/config/jest/console.js
@@ -3,12 +3,12 @@ const originalWarn = console.warn

 // this is here to silence a warning related to useStaticRendering
 // xref https://github.com/GMOD/jbrowse-components/issues/1277
-jest.spyOn(console, 'error').mockImplementation((...args) => {
-  if (typeof args[0] === 'string' && args[0].includes('useLayoutEffect')) {
-    return undefined
-  }
-  return originalError.call(console, args)
-})
+// jest.spyOn(console, 'error').mockImplementation((...args) => {
+//   if (typeof args[0] === 'string' && args[0].includes('useLayoutEffect')) {
+//     return undefined
+//   }
+//   return originalError.call(console, args)
+// })

The only reason we don’t get those warnings in the tests right now is because of that code snippet which silences them

[cmdcolin]

Note that the memory leak by using mainthreadrpc may not be really something that is good to ignore

We render large numbers of observer components when using SvgFeatureRendering for example (every single subfeatures is an observer)

Using #1727 does not fix this issue. Only something like #1733 can conceptually fix that e.g. skipping SSR on the main thread entirely