Focus trap doesn't work in React 18

[moroshko]

I'm using focus-trap-react 9.0.1 and the focus trap doesn't seem to work.
If I focus on the first <input> and press Tab twice, I land on the second <input> that sits outside the trap.
What am I missing?

<div className="App">
  <FocusTrap>
    <div>
      <input type="text" />
      <button>Submit</button>
    </div>
  </FocusTrap>
  <input type="text" placeholder="I am outside the trap" />
</div>

Codesandbox

[stefcameron]

That is strange. What you have there is all it should take.

I appreciate the repro. I can't repro this locally -- but I did notice that you're running this code in strict mode, and when not in strict mode, it works as expected.

So, what is happening in strict mode that's preventing the trap from working. Likely some violation is happening somewhere that's silently blowing up or preventing the trap from finding something, and causing it to render, but not activate. 🤔

[stefcameron]

Tracing this out, seems nothing is blowing up in strict mode. The trap gets created, everything looks good. And yet it silently just doesn't work.

[stefcameron]

I see. It's because in strict mode, React unmounts and remounts the <FocusTrap> after mounting it the first time. When the component is unmounted, the trap is deactivated, but not destroyed. When it remounts, the trap already exists, so nothing happens. And you're left with a deactivated trap.

React doesn't re-render on re-mount the second time, though, and doesn't re-execute the callback ref, so I will assume here that React is remounting onto the same DOM state as well, which means the trap, on remount, if exists, should check if it should be active and isn't and just reactivate and assume what it thinks the container elements are still exist in the DOM.

If React doesn't re-execute the callback refs, that won't trigger getting new DOM nodes for the container elements (when you don't specify the containerElements prop like you're doing in your sandbox) and so I'm not sure there's anything more that can be done. We have to assume the DOM hasn't changed. There's no approved way to "kick" the render can to trigger checking the DOM with the callback refs (that I know of, anyway). 🤷‍♂️

[stefcameron]

For the record, I am not a fan of this strict mode. For one thing, it violates correct assumptions about componentWillUnmount

Once a component instance is unmounted, it will never be mounted again.

(emphasis mine)

Strict mode violates this assumption. I get that React is looking forward to this day where they will decide which parts of the tree to unmount when the user goes away somewhere, but strict mode violates normal assumptions, and then they expect the entire community to not operate under those assumptions??

[stefcameron]

@all-contributors add @moroshko for bug

...Although I wouldn't technically consider this a bug, but nonetheless, whatever I may think, many people seem to run in strict mode, so I definitely appreciate the heads-up here. Thank you, @moroshko !

[allcontributors]

@stefcameron

I've put up a pull request to add @moroshko! 🎉

[stefcameron]

Will be published in 9.0.2

[moroshko]

Thank you @stefcameron for such a quick fix!

[stefcameron]

My pleasure!