Add React component stack

[jaril]

Original discussion: https://github.com/RecordReplay/devtools/discussions/3809

https://www.notion.so/replayio/React-DevTools-v3-c702fd808cfd402195f5296de1395d28

When Replay pauses the paused component should be selected in the tree.
When Replay pauses we should show the owner list as a stack in the pause panel

[jasonLaster]

Adding this discussion from
https://twitter.com/sophiebits/status/1516898885595066368

From @sophiebits

Something like:

render [paused here]
Child (render due to context change)
Middle2 (did not render; memo bailed out)
Middle1 (render due to new props; provided new context)
Parent (render due to setState)
setState
updateParent
updateParentIfNeeded
handleClick

[jasonLaster]

Also similar

#6199 -- phantom components

[bvaughn]

Just wanted to drop a few initial thoughts here from the React DevTools perspective:

1. AddIng component stacks seems relatively easy for us to do¹
2. Showing whether components higher up in the tree rendered or bailed out seems doable¹
3. Stepping to parent render seems doable²
4. Showing when the state update was scheduled (and the call stack for it) seems like a much harder problem in general³

¹ I think we might need to change the way React DevTools and Replay work together to do this. Right now Replay hardcodes DevTools internal "operations" array and feeds it back when viewing the session. The information we feed the DevTools frontend here isn't sufficient to determine the component stack or whether or not specific components rendered. I think we have the information somewhere though, given the "inspectElement" functionality works. I have holes in my knowledge about how this works in Replay though.

² This would require some added functionality on the Replay devtools (or backend?) but should be doable assuming we solve the technical constraints of the point above.

³ React's state update queue isn't exposed to React DevTools. (Even the React DevTools Profiling tools have some difficulty associating a chunk of work with the update that scheduled it.) This functionality seems like it would be extremely helpful but I'm not sure how we'd implement it without adding a lot of React+version specific knowledge into Replay.

[bvaughn]

Small follow up after a chat with @hbenl to fill in some gaps in my understanding:

• Items 1 and 2 above should be doable if we add some new APIs to the React DevTools backend that's embedded in the Replay browser (the thing that currently records the operations array and bridge protocol version). The interesting question here is how we'd add those methods (preferably without forking the React DevTools backend).
  • We'd also need to pass this extra information to the Replay devtools so it can show it alongside of the call stack.
• Item 3 above is doable but will require the React DevTools backend and Replay browser/backend to talk to each other. (React DevTools has a reference to a function. It would need to pass that to the Replay backend and ask it to jump to the last time that function ran.)

[bvaughn]

Took a look at this today on my flight: https://github.com/bvaughn/react/tree/devtools-get-current-component-stack-spike

If we wanted to move forward with it, it would likely mean forking React DevTools (for now) as I don't think the team would want to add and support this new API. That's probably okay though, especially as a short term / medium term thing.

There is something we should discuss though: I don't think we can support component stacks for production React apps, only DEV ones. Most of React's "current fiber" tracking is DEV only, with the exception of the workInProgress variable in the work loop– but that variable isn't accessible to most code (including React DevTools). React only exposes a limited set of methods to DevTools, and while it does expose a getCurrentFiber method, that method only works for DEV bundles.

Let's chat about how to proceed!

[bvaughn]

A few of us (@jaril, @jasonLaster, @jcmorrow, @loganfsmyth, @markerikson) spoke in person this afternoon about the component stacks topic, and I promised to write a summary of my thoughts and the constraints on my flight home so that's what this comment is about.

General architecture

For a refresher on how React DevTools works, see this overview. The rest of this post will use the following terminology:

• devtools – Shorthand for React DevTools (not Replay)
• backend and frontend – As described in that overview doc
• component "instance" – A specific instance of a component within a React application (e.g. the Button component may be rendered many times, but one "instance" is in the login form)

Currently, Replay makes use of a fork of devtools that listens to messages being sent from the backend to the frontend and records them as annotations. Then when viewing a recording, Replay forwards those annotations to the frontend (simulating what the backend did during recording) and the frontend displays the React component tree. If the frontend needs to talk to the backend (e.g. to inspect a component's props) Replay forwards the message to the backend to be evaluated.

We may need to change the way this works so that we can support features like component stacks and profiling. More on that below.

Features

There are a lot of potential features we could build on top of the concept of component stacks. Some are easier than others. Here's my thinking about the order we should probably approach them in.

1. Show component stack when paused within a React component that's being rendered.
2. Support stepping up/out of the component to its parent component.
3. Step back/forward to other times the currently paused component rendered at this spot within the React tree.
4. Support stepping down/into (or over/through) child components.

Note that all of the features being discussed in this post will only be supported for React development builds because React does not track or expose the concept of the currently rendering component in a way that devtools can access for production builds. (Perhaps this is a change that we could negotiate with the React team but I'm skeptical.)

Let's take a look at each of these features below and talk about the steps/constraints we're dealing with.

1: Show component stack

I've created an experimental branch that adds a few API methods (like getCurrentComponentStack) to devtools that the Replay browser could call when paused at a specific point in order to see if (1) React is currently rendering and (2) what the current component stack is:

import { activate as activateBackend } from 'react-devtools-inline/backend';

// API returned during DevTools initialization:
const devtoolsAPI = activateBackend(contentWindow);

// API methods can be called later, when paused at a point:
const componentStackOrNull = devtoolsAPI.getCurrentComponentStack();

The API would either return null (if React isn't currently rendering a component) or a structure like this:

// Example component stack array
[
  {
    // False if this component was rendered as part of the current update;
    // true if this component "bailed out" (memoized).
    didBailOut: boolean,

    // User-friendly display name (e.g. "AdminPanel", "Suspense", "Fragment")
    displayName: string | null,

    // If this node in the component stack is user code, this will be a class or function.
    // Otherwise it will be null for built-ins (e.g. Fragment, Suspense).
    type: React$Node | null,
  },

  // Other components ...
]

I don't think this functionality would require changes in the Replay browser, but I think it would require changes on the Replay devtools and backend.

Replay browser changes

• The Replay browser would need to expose the react-devtools-inline APIs (on the window/global?) so that they could be called by the Replay devtools.

Replay devtools changes

• When paused at a point, Replay devtools would need to call the new getCurrentComponentStack API (using ThreadFront.evaluate?) to get the possible component stack.
• If a component stack is returned, Replay devtools would need to render it below the call stack.
  • Components where didBailOut === true should be rendered as dim (or with some other UI treatment to show that they bailed out, cc @jonbell-lot23).

Note that there's one interesting caveat here: React DevTools might not be able to reliably tell if the component that's currently being inspected (paused on) rendered or bailed out. That's because React doesn't set the PerformedWork flag until after the component finishes rendering. This might be okay though, since the function is called regardless of whether the component bails out or not. The only way to know for sure would be for Replay to seek ahead to the commit and then ask devtools whether the component finished rendering or not (more on this below).

If this became a sticking point, we could always drop the different styling (showing whether a component rendered or bailed out) and just show the component stack with one visual style.

2: Step up/out to parent component

Building on top of the previous feature, we could allow users to step up the component stack (from the current component to its parents) just like they are able to step up the call stack. In order to support this, I think we'd need to expose some new functionality on the backend.

A naive way to implement this would be to expose an API that seeks from the current point backwards, to the most recent time a particular function was invoked. This wouldn't handle all cases though– because a single function (or class) could be rendered multiple times within a React tree (e.g. Replay's own Button component).

I think that in order to distinguish between multiple "instances" of a component, we would need some way to associate a component with its "fiber". So the API we would really need would be something more like "when was the last time this function was called that was also associated with this specific object instance?"². I'm not sure exactly how we would build this, since a React component doesn't even have direct access to its "fiber" (but the function.caller does).

Note that future planned changes to React¹ may add further complications but I think we could address them with a similar object tracking approach.

3: Step between other render passes

Building on top of the previous feature, we could also allow users to jump between the other times the currently selected component was rendered. In many cases, this would be the same thing as stepping between breakpoints. The difference would be shared components (e.g. Replay's Button component) in which case the React-aware breakpoints would be scoped to a component "instance" (the component's specific location within the React tree, e.g. the login Button).

Another way of viewing this is that it's basically extending Replay's existing breakpoint logic and filtering by React fibers. In other words, look at every time a function was invoked– and filter out the invocations that are not associated with a specific fiber². I think we could leverage the new Replay functionality mentioned above to do this?

4: Step down/into children

Building on top of the previous feature, we could also allow users to step down into a component's children (at least those that rendered without bailing out).

There are several challenges with this:

1. If we are currently paused while a component is being rendered, React devtools doesn't know which children will end up rendering and which will bail out. To determine this, we would need to seek forward to when the work in progress is "committed" and then analyze the tree.
2. The next React commit might not be the one our pause point is part of. That's because concurrent React may yield while rendering (or pre-rendering) to handle a higher priority update or to allow "suspended" I/O to finish.
3. There's no guarantee that a rendering component will ever get committed. Sometimes an update fails due to an error or is overridden/replaced with a higher priority update. To determine this, we would need to see which comes first: a commit that contains the current component instance or another render of the same component instance. (Note that future planned changes to React¹ may add further complications to this as well.)

We would need to add additional functionality to both the React devtools backend and Replay.

React DevTools backend

First, the component stack structure returned by devtools would need to be updated to include a few additional attributes:

// Example component stack array
[
  {
    // Same attributes as before:
    didBailOut: boolean,
    displayName: string | null,
    type: React$Node | null,

    // New attributes:

    // Uniquely identifies the component instance within the React tree.
    // This is required because the same class/function may be rendered multiple times in a React app.
    componentID: any,

    // Uniquely identifies the React renderer instance on the page.
    // This is required because (in rare cases) there may be more than one copy of React on a page.
    rendererID: any,
  },

  // Other components ...
]

Secondly, devtools would need to expose a new API to crawl a committed root and return a boolean noting whether a specific component was part of that render:

const value = devtoolsAPI.wasComponentRenderedDuringTheCurrentCommit(rendererID, componentID);

Note that this API would only be safe to call at the point when a React tree was being "committed" since any other time the fiber tree might contain pending changes that make it unsafe to traverse and reason about.

Replay changes

Because of the constraint mentioned above, Replay would need to seek to a commit point before calling the wasComponentRenderedDuringTheCurrentCommit method. (I'm not sure how this would work so we'd need to talk more about it. Maybe React devtools could tell Replay to bookmark commit times as part of the recording metadata?)

Presumably, Replay could seek forward through commits until it found the next one that contained the component instance. This would work in most cases, but would not handle the case where a particular component render was never committed (due to an error or a higher priority update). I think that to rule out this case, Replay would need to only consider future commits that occurred before the next time the component instance were rendered. (Note that future planned changes to React¹ would likely further complicate this though and maybe make it impractical unless React and React DevTools add new functionality to more explicitly track bailouts, which may conceivably happen in order to support the recent Timeline profiler, but I don't think it is currently planned.)

---

^{1 – Currently each fiber in the React tree has an "alternate" (a copy of the fiber). React uses this structure to clone/fork part(s) of the tree for updates while still preserving the "committed" tree as pristine (in case the update fails or is preempted). There are plans to refactor this structure to something that supports many forks of the committed tree. This will unlock functionality like pre-rendering multiple potential future states to support quick animations/transitions. This change may complicate Replay's filtering logic.}

^{2 – Open question: Is there a way to associate a function call with metadata like this?}

[bvaughn]

Note to self that I may be able to add some of these features to React DevTools (upstream) behind a feature flag. If there was concern, this wouldn't have to be published anywhere. We could build the Replay release (from source) ourselves.

Also, I wonder if I could write a proposal for the current fiber ref to be available in production bundles only if the DevTools hook was present?

[markerikson]

Obviously you're the expert on this and not me, but that sounds like a potentially workable idea!

[bvaughn]

Crazy thought RE: "this only works in DEV bundles because of the current fiber ref"

React has enough info (on the package export) to specify the version number running.

It would be hacky but Replay could swap out a production version of React for a DEV version during the replay session if we wanted to 😅 This could change behavior (because of things like strict mode) so maybe it would be more complicated than we'd want in some cases. Interesting thought experiment though.

[bvaughn]

A possibly less crazy idea would be swapping production version for profiling version if we wanted to retroactively run profiling.

[markerikson]

Huh. How would this work, given that libraries are normally bundled together?

[bvaughn]

Yeah! It wouldn't work for a lot of cases, but it's a fun idea for some of them 😄