TS: react-dom `root.render()` links to a class component's render() when root is declared outside
Maintainer thường phản hồi trong vòng 1 ngày
Một pull request liên quan đã được merge.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- react, typescript
- Lĩnh vực
- devtools
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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 alet popupRoot: Root | nullin 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:
- https://github.com/colbymchenry/codegraph/blob/8fe31569926680af6e5e7d616bf178a6fee053c7/src/resolution/name-matcher.ts#L12839-L12851 (
enclosingScopeStartLine) - https://github.com/colbymchenry/codegraph/blob/8fe31569926680af6e5e7d616bf178a6fee053c7/src/resolution/name-matcher.ts#L12853-L12859 (
inferLocalReceiverType, "Bounded to the enclosing scope")
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:
- When the enclosing-function scan finds nothing, fall back to the outer functions' and the module's top-level declarations (
let/const/varwith 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. - For an untyped
const x = f(…)wherefis 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. - Keep the by-name strategy from picking a React class component's
render(a method on a class thatextends Component/PureComponent) for a receiver that is notthis. React calls that method itself; project code never callsx.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).
renderis 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_KERNELunset). 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
rendermethods) avoids this through the receiver-word scoring or picks one of them.
- Ngôn ngữ chính
- C
- Star
- 73.2k
- Fork
- 4.7k
- Merge trung bình
- 11 giờ 28 phút
- Pull request đã merge (30 ngày)
- 596
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của colbymchenry/codegraph
-
codegraph ui - does not workĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
colbymchenry/codegraph#1900 · 2 bình luận · 5 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
colbymchenry/codegraph#1700 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
colbymchenry/codegraph#1535 · 2 bình luận · 2 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 63/100
colbymchenry/codegraph#1403 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent-target
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
colbymchenry/codegraph#649 · 5 bình luận · 50 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của colbymchenry/codegraph
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
polhenarejos/pico-fido#302 ·
-
开发板墙缺少 ESP32_S31_MOSAICOĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
espressif/esp-vision#16 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
libsdl-org/SDL#16577 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày
-
halt_error adds a trailing newline for non-string input, contrary to the manualCó thể đã có người làm @Huang-404-Q đã nhận hôm nay. Đang mở
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 2 ngày