I don't know what you mean by "custom debug information". Can you given an example of what DevTools looks like now (with your custom renderer) and what you'd like it to look like?

I am working on a project where React is running in a JS container and translated into native Flutter widgets. For that, I have a React reconciler that sends incremental updates over a bridge to Flutter and updates the Flutter widget tree (a bit similar to RN).

Now, I'd like to add some debug information, e.g. the Flutter widget ID to the React Instance that was created by the reconciler. Right now, I am using an ugly hack:

export function Box(props: BoxProps) {
  return React.createElement("Box", props);
}
debugSetupComponent(Box);

export function debugSetupComponent<P extends {}>(func: (props: P) => ReactElement<P>) {
  Object.defineProperty(func, "defaultProps", {
    get: () => {
      return { __instance__: [undefined] };
    },
  });
}

Basically, debugSetupComponent injects an array which I can manipulate later into the props via a defaultProps-hack. That survives freezing and because of shallow props-copying the same array will appear later in the reconciler.

Now consider a simple createInstance function (of course what I am doing is a bit more complex):

  createInstance: (type, props, _rootContainerInstance, _currentHostContext, _workInProgress) => {
    const id = ... // assign some ID for the native instance
    const instance = ... // setup the native instance
    props["__instance__"][0] = id; // fill debug info

This shows up like this in the React devtools:

But, it would be much nicer if I wouldn't need the defaultProps hack that introduces a mutable backdoor into the props.

Thank you for the detailed response @derolf! That's an interesting intermediate solution you've come up with.

As for your initial issue, I'd like to think more about the proposed getInstanceDebugInfo.

But maybe we can talk about getTextInstanceDebugInfo first. DevTools doesn't show TextInstance types in the UI. (It also doesn't show e.g. portals or fragments). I don't think we have any plans to change that, so I'm not sure the getTextInstanceDebugInfo method makes sense (even though I see why you'd propose it– given the parallel between createInstance and createTextInstance methods.

Well, any sort of getInstanceDebugInfo or getTextInstanceDebugInfo could populate the debug information to the closest ancestor in the component tree.

Not sure I follow. TextInstance is always a leaf.

Is your custom renderer somewhere that I could see it / try it, by chance?

Sorry, that’s not possible (yet), it's developed in-house, but we're planning to open-source it.