Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

2.0: grouping isPending(x) with x() in one effect changes which lanes a later write opens

Đang mở
  • Có gì không ổn?
#4,398 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đá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
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, typescript
Lĩnh vực
frontend

Hướng nghiên cứu

Start with the failing test pin verdict-memo-flight-no-reask.test.ts mentioned in the issue, then compare the grouped and split cases in review-4397/zz-grouping.test.ts and the probe results in probe-h-wip.txt. Trace how isPending(m1) and m1() participate in an open transaction when the later setT(1) runs. Done means a test establishes the intended behavior from the #4284 ruling and JSX grouping no longer changes which lane questions m1 asks.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

What happens

An async memo m1 reads two verdict memos:

const m0  = createMemo(() => ask("m0",  1 + latest(s) + s()));
const m0b = createMemo(() => ask("m0b", 10 * (latest(t) + t())));
const m1  = createMemo(() => ask("m1",  1 + m0() + m0b()));
// under a Loading boundary
setS(2); /* 12 ms later */ setT(1);

With #4397, m1 asks each question once, but which questions it asks depends on how the readers are grouped:

  • Grouped, one render effect reading ${isPending(m1)},${m1()}: m0:4, m1:5, m0b:10, m0b:20, m0:5, m1:26
  • Split, one effect reading isPending(m1) and another reading m1(): m0:4, m1:5, m0b:10, m0:5, m1:15, m1:16, m0b:20, m1:26

The final value is the same in both shapes (26), but the grouped shape never asks or shows the t write's lane views of m1 (m1:15/m1:16).

Why

m1 is plainly pending while m0's flight is up (F-9). The grouped effect reads isPending(m1) beside m1(), so it, and m1 with it, sits in the s write's transaction. The later setT(1) then merges into that open transaction instead of opening its own lane. In the split shape, the value effect isn't held that way, so t gets its own lane and m1 asks its lane questions there.

On next, every shape asked alike only because m1 was re-derived as a verdict reader at every verdict change. That re-derive is the duplicate-ask bug #4397 fixes: each lane question was asked 2–4 times.

Ruling needed

Per the #4284 ruling, JSX grouping must never change the result. Should a later write merge into an open transaction, or open its own lane, when a render effect reads isPending(x) beside x() (the F-6 / D-23 "holds like x() alone" case)?

A test.fails pin in #4397 (verdict-memo-flight-no-reask.test.ts) documents the grouped vs split difference. Probe matrix and repros: review-4397/zz-probe.test.ts, zz-grouping.test.ts and probe-h-wip.txt (project repro folder).

Related, still open

  • In the held two-action and two-verdict probes, m1:15 is still asked twice (base asked it 3–4 times).
  • With #4393 (R5), a second write during the hold (s=3) still asks m0:5 twice.
Ngôn ngữ chính
TypeScript
Star
36.2k
Fork
1.1k
Merge trung bình
10 giờ 28 phút
Pull request đã merge (30 ngày)
379

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của solidjs/solid

Tất cả issue của solidjs/solid

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.