Fiber is undefined when using concurrent features about its-fine HOT 4 CLOSED

(I think) I fixed it by first trying root, and if it's not found on there, then try root.alternate:

export function useFiber(): Fiber<null> | undefined {
  const root = React.useContext(FiberContext)
  if (root === null) throw new Error('its-fine: useFiber must be called within a <FiberProvider />!')

  // In development mode, React will expose the current component's Fiber as ReactCurrentOwner.
  // In production, we don't have this luxury and must traverse from FiberProvider via useId
  const id = React.useId()
  const fiber = React.useMemo(
    () => {
      const rootFiberOptions = [root, root.alternate]
      for (const possibleRootFiber of rootFiberOptions) {
        if (!possibleRootFiber) continue
        const fiber = traverseFiber<null>(possibleRootFiber, false, (node) => {
          let state = node.memoizedState
          while (state) {
            if (state.memoizedState === id) return true
            state = state.next
          }
        })
        if (fiber) return fiber
      }
    },
    [root, id],
  )

  return fiber
}

According to this comment in the react source code:

The current, flushed, state of this fiber is the alternate.

So I assume the memoizedState, which contains the id, has not yet been added to the "new" fiber, only to the alternate fiber.

from its-fine.

Maybe root.alternate || root would also work, but I'm not familiar enough with the React internals.

@CodyJasonBennett I'm not sure if you're familiar with React internals, any thoughts on this issue? Should I make a PR, or would you need a reproduction first?

from its-fine.

That is correct, React uses a double-buffered linked list data structure for Fiber, where alternate is the WIP Fiber node. It does point to either the new or old Fiber though, we'd need a way to discern which the root node is.

from its-fine.

Another question is whether the FiberProvider's fiber is run at the same time as the component we're calling useFiber in. Might it be that due to scheduling, the FiberProvider is flushed, but the component isn't yet? And that in that case, some parent fibers already switched to their alternates but children haven't yet?

Just speculating, the React source and all the concurrent features are still a bit of a blur to me.

from its-fine.