Fix HMR errors

[dusave]

Changelog

New

• Add optional chaining checks to prevent undefined references when hot-module reloading. This work is designed to support HMR in the dotcom monorepo specifically.

Changed

Removed

Rollout strategy

• Patch release
• Minor release
• Major release; if selected, include a written rollout or migration plan
• None; if selected, include a brief description as to why

[github-actions]

👋 Hi, this pull request contains changes to the source code that github/github depends on. If you are GitHub staff, we recommend testing these changes with github/github using the integration workflow. Thanks!

[github-actions]

size-limit report 📦

Path	Size
packages/react/dist/browser.esm.js	98.6 KB (+0.03% 🔺)
packages/react/dist/browser.umd.js	99.03 KB (+0.15% 🔺)

[changeset-bot]

🦋 Changeset detected

Latest commit: f3a5ff2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@primer/react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[joshblack]

Just curious, do we know why this ref is undefined when doing our upstream work in dotcom? 🤔 Specifically for HMR. It seems like something is happening with the context value being passed along that's different from how it's being represented in TS?

[camertron]

We think it's because the DOM is being replaced, but honestly that's just a theory 😬

[dusave]

Like @camertron said, we think the DOM is being rebuilt and inserted, which temporarily seems to make the refs undefined. However, it's barely undefined long enough to matter. By the time the page renders, everything is rehydrated and all works fine. But for that split second while it's being swapped out, React throws a fit.

[joshblack]

I would have thought the ref would be stable since it ultimately is coming from useRef and the value returned from that wouldn't be undefined between renders 🤔 (although current totally would if the DOM is changing)

Could it be that the context value (MenuContext) is changing during HMR? It seems like we're explicitly casting this value as being defined in:

react/packages/react/src/ActionMenu/ActionMenu.tsx

Line 255 in f3a5ff2

} = React.useContext(MenuContext) as MandateProps<MenuContextProps, 'anchorRef'>

but with the HMR stuff here that doesn't seem to be the case

[dusave]

It could be, yes. I went down the rabbit hole of trying to untangle that type and make it optional. However, this raised a couple of other flags:

1. Under normal operation, that ref should be defined, so I'm not sure we want to mark that as optional for production-level usage.
2. Trying to satisfy the type checker marking that as optional was brutal. Just changing that one type to optional started throwing a myriad of errors where it could be undefined.

This seems like a fairly benign option to allow HMR to work, but at the same time, it does feel like we're having to make special changes just to support HMR, which doesn't make me feel great 😬

[camertron]

Based on our discussion during our sync meeting on Monday (11/18), let's merge this for now and conduct further research async 👍