Fixed incompatibility between react-debug-tools and useContext() #14940
Conversation
|
Great! Thanks a lot! |
|
Well done! Thx! |
| @@ -93,6 +93,7 @@ function useContext<T>( | |||
| context: ReactContext<T>, | |||
| observedBits: void | number | boolean, | |||
| ): T { | |||
| nextHook(); | |||
There was a problem hiding this comment.
not sure if relevant, but we add the workinprogresshook to the list only when DEV. so hook.next behaves differently in prod vs dev https://github.com/facebook/react/blob/master/packages/react-reconciler/src/ReactFiberHooks.js#L527-L529
There was a problem hiding this comment.
Good catch. My test had a blindspot here since the null hook would just re-initialize the state. I'll change it to throw if that happens.
There was a problem hiding this comment.
Hmm... 🤔 I think this might be trickier than a simple __DEV__ check can account for. It's not a matter of whether react-debug-tools is itself in production or development mode, but whether the renderer it's interacting with is.
bvaughn
force-pushed
the
fix-react-debug-tools-useContext
branch
2 times, most recently
from
d8b9115 to
73a1cae
Compare
bvaughn
force-pushed
the
fix-react-debug-tools-useContext
branch
from
73a1cae to
e777462
Compare
|
Maybe we can change it to add the hook to the list whether dev or prod. I remember adding it only so we could do the warning for when the order doesn’t match across renders. It doesn’t serve any other purpose. |
|
Yeah, I'm looking into that now. |
|
Previously in production mode, If this change is unacceptable, then we have a few alternatives:
The above two alternatives have a couple of benefits:
I would be interested in hearing @sebmarkbage's thoughts on this. |
bvaughn
force-pushed
the
fix-react-debug-tools-useContext
branch
from
1e9f755 to
3f5cde5
Compare
|
I'd err on the side of keeping context calls very cheap and accepting some integration fragility (DevTools pass the DEV flag) as a tradeoff. With a test that shouldn't even be that fragile. |
|
My M.O. in any case like this is to error on the side of adding more implementation complexity to the DEV side and keep the prod side clean. In this case, let’s take a step back and ask why DEV differs. It’s easy to assume that context is the odd one out here and that all other hooks goes into the hooks list. That’s not true conceptually though. Some of the hooks we have now don’t have to be stateful (eg useEffect without a dep list nor destructor). In the future, the hooks we want to add will also not be stateful. So the list we have right now is not so much the canonical “hooks list”. It’s only the “stateful hooks list”. In fact, in the future some of them might have more than one entry. I don’t know exactly but I’m guessing that the only reason @acdlite added context to this set in DEV is that it makes it easier to issue warnings that enforce call order and preserve our option to keep them. However, by reusing the production mechanism for this, I think we’ve also accidentally introduced a bug (prod/dev behavior) that is observable through the invariant calls that only happen in one path. The lesson learned from “current owner” is that it’s a bad idea to rely on subtle production behavior for dev warnings because they’re not always going to overlap. That’s why we have “current debug frame” instead for the warning info. I think it would be appropriate to do the same here if we want to preserve some of the dev warnings. If we want to conceptually model the warnings as the user facing api contract (every primitive hook call is one hook in that exact order). Then we should explicitly model that in dev. Which requires dev to have a separate hooks list that overlaps mostly with the stateful hooks list (but not exactly). |
Interesting. I hadn't considered this option, but I dig it. |
|
I'll expand our hook ordering test to make sure it covers all of the hook types. There are definitely cases where we'll warn about other things as well when the order changes (e.g. inputs array changing) but at least we can ensure that we're warning about the order changing. |
|
Okay. I've refactored this to a DEV-only list of hook names to verify ordering. I've also updated our tests to cover more cases (including several that failed prior to this change). There are a couple of potential follow up things we could do (which I left TODO comments for). |
|
ReactDOM: size: 0.0%, gzip: 0.0% Details of bundled changes.Comparing: 0b8efb2...3899681 react-dom
react-art
react-native-renderer
react-test-renderer
react-reconciler
Generated by 🚫 dangerJS |
bvaughn
changed the title
This adds a small amount of overhead, so I'm not sure if it will fly. I think it might be necessary though in order to support the react-debug-tools package.
This enables us to warn about more cases (e.g. useContext, useDebugValue) withou the need to add any overhead to production bundles.
bvaughn
force-pushed
the
fix-react-debug-tools-useContext
branch
from
ef8bd2c to
c2fc659
Compare
|
Rebased and updated DEV mode to also check for mount vs update using the |
| '1. useReducer useReducer\n' + | ||
| '2. useState useRef\n' + | ||
| ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n', | ||
| ]); |
There was a problem hiding this comment.
This change wasn't strictly necessary but it seems like this test is a bit more robust (and reads better) if it uses our toWarnDev check.
An issue was reported in facebookarchive/redux-react-hook/issues/34 where DevTools caused a runtime error when inspecting a component that used a
useContexthook. I determined the cause to be due to the fact that theuseContexthook inside ofReactDebugHooksdoesn't callnextHook()to advance the list, which causes subsequent hooks to be mismatched.Initially, I thought the fix would be to simply add that call– but React itself is inconsistent with how it treats
useContextbetween development and production builds. This presents a problem for thereact-debug-toolspackage– it either breaks in development or production mode.I've addressed this by refactoring our hooks ordering checks to use a separate, DEV only list (stored on fibers as
_debugHookTypes). This way we don't have to rely on a hook being added to the hooks list in order to be validated, and code likeReactDebugHooksdoes not have to worry about inconsistent behavior between DEV and PROD bundles, (and we avoid adding additional overhead to PROD bundles).This changed caught a couple of additional warnings in existing tests. I've beefed out or test coverage in this area as well for going forward.
A few alternative fixes were considered:
useContextimplementation in React to usemountContext/updateContext(instead of callingreadContextdirectly) so that it's consistent between modes.react-debug-toolswill work with earlier hook releases too).buildTypeflag toinspectHooks(telling it whether React is running in production mode).ReactDebugHooks.useContextthen conditional callsnextHook()based on this flag.