Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

TS: react-dom `root.render()` links to a class component's render() when root is declared outside

已关闭
#2,589 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

已经有一个关联 PR 被合并了。

  • #2807 来自 @inth3shadows —— 已关闭,未合并
  • #2811 来自 @colbymchenry —— 已合并

评估

难度
4/5
预计耗时
3-5 天
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
react, typescript
领域
devtools

调研方向

Start in src/resolution/name-matcher.ts, at matchMethodCall, inferLocalReceiverType and enclosingScopeStartLine, to see why a receiver declared outside the calling function gets no type. Reproduce with the four files in the issue (popup.tsx, popup2.tsx, popup3.tsx, Boundary.tsx) and check that no calls edge reaches Boundary.render. Done when those edges disappear while the annotated control in popup3.tsx stays unresolved as it is now.

由索引模型根据 Issue 内容生成。

描述

Summary

root.render(<X />) on a react-dom Root gets a calls edge (instance-method, confidence 0.7) to the project's one class render() method (an error boundary, here) in two shapes:

  • the receiver is declared outside the calling function: a module-level let root: Root, or a let popupRoot: Root | null in an enclosing function that a nested function renders through;
  • the receiver is a local initialized from a call: const r = createRoot(el).

When the receiver is annotated inside the calling function (const r: Root = createRoot(el), let r: Root | null, or a parameter root: Root), #2169's rule applies and no edge is created, which is correct: Root is not declared in the project. Found on a real React app, where two editor popup helpers (popupRoot.render(…)) were listed as callers of ErrorBoundary.render.

Reproduction (verified)

On main at 8fe31569, built from source, Linux (WSL2), Node 22.23.2, WASM extractor (CODEGRAPH_KERNEL=0).

src/Boundary.tsx

import { Component } from "react";
export class Boundary extends Component<{ children?: React.ReactNode }> {
  render() { return this.props.children; }
}

src/popup.tsx

import { createRoot, type Root } from "react-dom/client";
let root: Root | null = null;
export function showPopup(el: HTMLElement) {
  if (!root) root = createRoot(el);
  root.render(<div />);
}

src/popup2.tsx

import { createRoot } from "react-dom/client";
export function mount(el: HTMLElement) {
  const r = createRoot(el);
  r.render(<div />);
}

src/popup3.tsx (control: no edge expected, none created)

import { createRoot, type Root } from "react-dom/client";
export function mount3(el: HTMLElement) {
  const r: Root = createRoot(el);
  r.render(<div />);
}
export function mount4(root: Root) {
  root.render(<div />);
}

codegraph init -i, then every edge that is not contains / imports / exports:

src/popup.tsx:showPopup -[calls L5]-> src/Boundary.tsx:method:render   {"confidence":0.7,"resolvedBy":"instance-method","refName":"root.render"}
src/popup2.tsx:mount -[calls L4]-> src/Boundary.tsx:method:render      {"confidence":0.7,"resolvedBy":"instance-method","refName":"r.render"}

popup3.tsx lines 4 and 7 stay unresolved (r.render, root.render).

Two more shapes, same result:

let modRoot: Root;                                   // module scope, no union
export function a1(el: HTMLElement) { modRoot = createRoot(el); modRoot.render(<div />); }
// a1 -[calls L3]-> Boundary.render

export function outer(el: HTMLElement) {
  let popupRoot: Root | null = null;                 // declared in the enclosing function
  function renderPopup() { popupRoot!.render(<div />); }
  popupRoot = createRoot(el);
  return renderPopup;
}
// renderPopup -[calls L5]-> Boundary.render

A let localU: Root | null declared and used in the same function gives no edge, so the | null union is not the trigger; where the declaration sits is.

Observed: showPopup, mount, a1 and renderPopup each call Boundary.render.
Expected: no edge. The receiver is react-dom's Root, whose render is outside the project.

Likely cause (inferred from reading the code)

matchMethodCall asks inferLocalReceiverType for the receiver's type, and that scan starts at the tightest function or method enclosing the call:

A declaration at module scope, or in an outer function, is above that start line, so no type is inferred. For const r = createRoot(el), the TS patterns only read = new X(…) and name: X, so a call initializer yields no type either:

With no inferred type, #2169's "a type the project doesn't declare is an outside type" check never runs:

and the by-name strategy takes the only same-language method named render at confidence 0.7:

Possible directions, roughly from narrowest to broadest:

  1. When the enclosing-function scan finds nothing, fall back to the outer functions' and the module's top-level declarations (let/const/var with an annotation). A module-level binding can't be shadowed by another function's local, so the "same-named variable in another function" concern behind the scoping does not apply to it.
  2. For an untyped const x = f(…) where f is imported from a package outside the repository (react-dom/client), treat the receiver as external and decline, in the same spirit as #2120's out-of-repo import rule for bare calls.
  3. Keep the by-name strategy from picking a React class component's render (a method on a class that extends Component / PureComponent) for a receiver that is not this. React calls that method itself; project code never calls x.render() on a component instance.

Related

  • #2169 (an outside declared type calls that type), the rule these shapes miss.
  • #1987 / #2028 (built-in method names on untyped receivers). render is not a built-in name, so that gate does not cover it.
  • #1651 (closed, not merged: typed external receivers).

Not checked

  • The Rust kernel path (default, CODEGRAPH_KERNEL unset). Resolution is shared, so I expect the same result; only the WASM extractor was run.
  • Other react-dom / React Native shapes with the same method name: ReactDOM.render(…) (identifier receiver, probably fine), hydrateRoot(…).render(…), and test renderers (const { rerender } = render(…)).
  • Whether a project with several class components (several render methods) avoids this through the receiver-word scoring or picks one of them.
主要语言
C
星标
73.2k
派生
4.7k
平均合并
7 小时 49 分钟
30 天内合并 PR
629

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

colbymchenry/codegraph 的其他 Issue

查看 colbymchenry/codegraph 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。