"rehackt" is causing unexpected behavior changes with React

Help
,
1

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):
tabs-no-rehackt

With rehackt:
tabs-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.

1 Like
2

Hey @abrenoch :wave:

Thats…odd. rehackt is a very thin wrapper around React and is mostly there to prevent some issues we saw with Next.js trying to statically analyze imports causing some pain for our users. It should have no bearing on runtime React by any means. You can get some more context from GitHub - phryneas/rehackt, especially nextjs release breaks server component use of Apollo query latest release · Issue #10974 · apollographql/apollo-client · GitHub which illustrates the issue we were running into.

@lenz any chance you have an idea why rehackt would even play a role here?

3

I should also ask, what version of React are you using?

4

Thanks for the fast response! Running v18.2.0.

Quite odd I agree - I’m 99% sure its not something silly I’m doing and not recognizing! :smile:

5

Rehackt is, if you’re not using next really just this code after removing the comments:

"use strict";
if (0) {
  module.exports = require("react");
}
module.exports.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED = undefined;
module.exports.__CLIENT_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE = undefined;
module.exports.__SERVER_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE = undefined;
Object.assign(module.exports, require("react"));

Which is pretty much equal to

module.exports = require("react");

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?

6

Hey appreciate the response @lenz !

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.

Thanks again for the quick response.

1 Like
7

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

2 Likes