Hey there, was trying out version 3.11.8 of the client and found myself encountering some completely new and unexpected behavior from React (v18.2.0)
For some context, the UI has tabs that swap out the contents of some virtualized lists. When changing tabs the previous scroll index is applied so the list returns to the last scroll position. This seems to work fine until rehackt is present in my package-lock, at which point the behavior of restoring that scroll position seems to break. Even after downgrading apollo client to 3.8.4 (last version we were on), if rehackt still exists we see the buggy behavior.
I’m hoping some gifs will help articulate this, recreating the issue in a separate repo/sandbox may take some work.
Without rehackt (present in package-lock):
With rehackt:
Again this is simply having rehackt exist in package-lock.json - not even being used/imported anywhere.
Looking at the apollo client change history, it appears this was added for nextjs compatibility… Is this altering the built-in behavior of react? I’m trying to understand why and how this issue arose.
just setting __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED etc. to “undefined” in case they were not present at all.
It a library now relied on these existing instead of them having a value, that could indeed change it’s behavior, but to do that, that library would have to import from rehackt. None of your code does that.
I would recommend that you check your lockfile if any other package gets upgraded during the presence of rehack - maybe your React version gets upgraded as a weird package manager side effect?
I agree it seems really unlikely rehackt is causing this, I only brought it up here after isolating changes my lock file to rehackt (which was still present after downgrading apollo client to a prior version and the problem still seemed to exist).
I’ll keep poking around at this and see if maybe I can put together a minimal reproduction of the issue.
Just a small update - whatever is causing this definitely isn’t rehackt. I tried out the 3.10.8 version of the client, which appears to use rehackt, and I’m not seeing the problem. It does however show up when updating to 3.11.0.
I’m still investigating though, I’ll update if anything new is found
Late follow up - Took a moment to revisit this and I’m not seeing the same behavior mentioned in the OP anymore. Maybe some other recent changes we made resolved the underlaying issue.
I’ll mark this comment as the answer - thanks for your help fellas, you’re appreciated!