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

[2.0] The MIGRATION.md replacement for `from()` keeps the upstream subscription after dispose; add a subscription helper

未关闭
#4,182 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@devagrawal09 已经在做这个了。

开始于 2026年10月21日。

  • #4212 来自 @devagrawal09 —— 未关闭

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
typescript

调研方向

Start with documentation/solid-2.0/MIGRATION.md and the consumeIterator behavior described in the issue; the minimal reproduction shows how disposal leaves the upstream subscription open. Compare the migration guidance with the From React page additions referenced in the payload. Done means the docs explain safe teardown and an official reusable subscription approach is available or the issue’s API proposal has a clear resolution.

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

描述

Describe the bug

documentation/solid-2.0/MIGRATION.md ("from / observable → async iterators / effects") recommends:

const value = createMemo(async function* () {
  for await (const val of observable$) yield val;
});

After the owner is disposed, the upstream iterator's return() is not called. It runs only when the upstream produces another value, which may never happen. The cause is that the generator is suspended at an await (inside for await), so its return() is queued behind the pending step. Solid's side is correct: consumeIterator calls return() on dispose and on supersede.

Your Example Website or App

Minimal repro inline below (signals-only).

Steps to Reproduce the Bug or Issue
import { createMemo, createRoot, createRenderEffect, flush } from "@solidjs/signals";

let push: (v: number) => void;
let closed = 0;
const observable$: AsyncIterable<number> = {
  [Symbol.asyncIterator]: () => ({
    next: () => new Promise(r => (push = v => r({ value: v, done: false }))),
    return: async () => { closed++; return { value: undefined, done: true }; }
  })
};

const dispose = createRoot(d => {
  const value = createMemo(async function* () { for await (const v of observable$) yield v; }, { loadingValue: 0 });
  createRenderEffect(value, v => console.log("value", v));
  return d;
});
flush(); push!(1); /* await a few microtasks */ flush(); // logs 0, 1

dispose(); /* await 50 microtasks */
console.log(closed); // 0: upstream still subscribed
push!(2);  /* await */
console.log(closed); // 1: closes only after the next upstream value

By contrast, a hand-written iterator whose return() unsubscribes synchronously behaves well. I tested:

  • isPending stays false while the memo waits for the next value;
  • loadingValue covers the first read;
  • return() unsubscribes immediately on dispose;
  • bursts coalesce into one update with a dirty flag.

It's about 20 lines and easy to get wrong:

function fromSubscription<T>(subscribe: (cb: () => void) => () => void, getSnapshot: () => T): AsyncIterable<T> {
  return {
    [Symbol.asyncIterator]() {
      let dirty = true, done = false;
      let wake: ((r: IteratorResult<T>) => void) | undefined;
      const unsubscribe = subscribe(() => {
        dirty = true;
        if (wake) { const w = wake; wake = undefined; dirty = false; w({ value: getSnapshot(), done: false }); }
      });
      return {
        next: () => {
          if (done) return Promise.resolve({ value: undefined, done: true });
          if (dirty) { dirty = false; return Promise.resolve({ value: getSnapshot(), done: false }); }
          return new Promise(r => (wake = r));
        },
        return: () => {
          done = true; unsubscribe();
          wake?.({ value: undefined, done: true }); wake = undefined;
          return Promise.resolve({ value: undefined, done: true });
        }
      };
    }
  };
}
Expected behavior
  • Docs: fix the MIGRATION.md snippet so disposal actually unsubscribes, and document (or flag in dev) that async function* + await delays teardown until the next upstream value.
  • API: provide a helper equivalent to React's useSyncExternalStore / Solid 1's from:
    const online = createMemo(() => fromSubscription(subscribe, () => navigator.onLine), { loadingValue: true });
    
    MIGRATION.md says this is expected to "move into @solid-primitives". Given how central external stores are to incremental migrations (keeping existing domain stores and putting Solid on top), it may be worth a minimal version in core. Either way, a correct, reusable implementation should exist somewhere official.
Screenshots or Videos

No response

Platform
  • OS: macOS (Darwin 25.5)
  • Browser: n/a (reproduced in Node v24.18.0 with vitest, importing source)
  • Version: solid next @ b0ad1df50 (2026-10-20, after 2.0.0-rc.16)
Additional context

This came up while documenting useSyncExternalStore for the From React page (solidjs/solid-docs#1664). The From React additions describe the hand-written iterator and warn against async function* for this.

主要语言
TypeScript
星标
36.1k
派生
1.1k
平均合并
11 小时 17 分钟
30 天内合并 PR
371

环境准备

从这里开始

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

solidjs/solid 的其他 Issue

查看 solidjs/solid 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

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