@solidjs/signals 2.0.0-rc.2 → 2.0.0-rc.20

package/dist/prod/core/action.js

@@ -1,14 +1,27 @@
-import { globalQueue, activeTransition, currentTransition, schedule, flush } from "./scheduler.js";
-
 import { isThenable } from "./async.js";
 
 import "./core.js";
 
-function restoreTransition(e, r) {
-    globalQueue.initTransition(e);
-    const t = r();
-    flush();
-    return t;
+import { joinFuture, newTransaction, enterAction, exitAction, resolveTx, schedule, actionDepth, flush, nextQuestion, setQuestion, question } from "./scheduler.js";
+
+/** A slice of the body runs in the action's transaction: the flush that
+ * carries its writes parks into it (`joinFuture` — merging whatever the tick
+ * already joined: O1, an action that opens in a tick owns it; a second
+ * action in the tick, or one called from the body, merges into the first).
+ * A resumed slice drains at once: the seam parks what it wrote (the action
+ * holds the transaction open) or, the body having returned, lands it. A
+ * nested action resuming synchronously inside the outer body does not drain
+ * — that would park the outer's remaining writes' frame mid-slice; the outer
+ * step's own return does. */ function inTransaction(t, n, e) {
+    // The slice and its flush ask this action's question (A18 provenance):
+    // the guesses it writes and the flights it starts are stamped with it.
+    const i = question;
+    setQuestion(n);
+    joinFuture(t);
+    const o = e();
+    if (actionDepth === 0) flush();
+    setQuestion(i);
+    return o;
 }
 
 /**
@@ -29,26 +42,40 @@ function restoreTransition(e, r) {
  * submission tracking layered on top. The shared name is deliberate.
  *
  * Wraps a generator function so each invocation runs as a single transaction
- * (a "transition") that batches every signal/store write between yields. The
- * surrounding UI sees one atomic update per yielded step; nothing is committed
- * until the action either completes or the next `yield` resolves.
+ * that holds every signal/store write between yields. The surrounding UI sees
+ * one atomic update when the action completes; nothing is committed until
+ * every action in the transaction has returned.
  *
  * `yield` is the transaction-safe suspension point: the action waits for a
  * yielded promise and re-enters the transaction before running the code after
  * it. A plain `await` does NOT — the runtime has no hook into an async
- * generator's internal await continuations, so writes to fresh signals
- * between an `await` and the next `yield` escape the transaction and commit
- * immediately. `await` is still the ergonomic choice for typed results; just
- * put a bare `yield` before any writes that follow it:
+ * generator's internal await continuations, so code between an `await` and
+ * the next `yield` runs OUTSIDE the transaction: writes to fresh signals
+ * commit immediately, and anything that creates a reader there — `until()`,
+ * `latest()`, a memo or effect, a mount — is created mainline, where a read of
+ * this action's held state makes it born held (A29): staged with the
+ * transaction and replayed at its commit. `await` is still the ergonomic
+ * choice for typed results; just put a bare `yield` before any write or
+ * reader creation that follows it — including the expression of the next
+ * `yield`, which is evaluated before the step re-enters:
  *
  * ```ts
  * const saved = await api.createTodo(text); // typed result
- * yield; // re-enter the transaction before writing
+ * yield; // re-enter the transaction before writing or reading
  * setTodos(t => { ... });
+ * yield until(() => todos.some(t => t.id === saved.id));
  * ```
  *
+ * The same holds inside an async helper the action yields
+ * (`yield (async () => { ... })()`): everything after its first `await` runs
+ * outside the transaction. An `await refresh(x)` or `await until(...)` there
+ * waits for this action's commit, which waits on the helper, so it hangs
+ * whenever `x` re-ran during the action (#4263) and works otherwise. Call
+ * `refresh(x)` in the generator once the helper returns; `yield` it only when
+ * the action needs the fresh value.
+ *
  * (For the same reason, don't call `flush()` inside an action body — it
- * drains the transaction mid-step.)
+ * cannot reveal the held writes and is refused.)
  *
  * Each call returns a `Promise` that resolves with the generator's return
  * value, or rejects if it throws. Pair with `createOptimistic` /
@@ -73,66 +100,72 @@ function restoreTransition(e, r) {
  *
  * await addTodo("buy milk");
  * ```
- */ function action(e) {
-    return (...r) => new Promise((t, n) => {
-        const i = e(...r);
-        globalQueue.initTransition();
-        let o = activeTransition;
-        o.oe.push(i);
-        const done = (e, r, u = false) => {
-            o = currentTransition(o);
-            const s = o.oe.indexOf(i);
-            if (s >= 0) o.oe.splice(s, 1);
-            // Re-adopt through initTransition like every other resumption site:
-            // a bare setActiveTransition leaves globalQueue._batch as a detached
-            // ambient batch, and anything registered before the scheduled flush
-            // (held writes on a merging transition, optimistic overrides,
-            // affects() marks) lands there with nothing to ever finalize it.
-                        globalQueue.initTransition(o);
+ */ function action(t) {
+    return (...n) => new Promise((e, i) => {
+        const o = t(...n);
+        // The action's transaction, held open until the body returns. The
+        // first slice's writes are carried by the tick's scheduled flush.
+                const r = newTransaction(false);
+        r.tt = 1;
+        r.nt = true;
+        const s = nextQuestion();
+        const done = (t, n, o = false) => {
+            resolveTx(r).tt--;
             schedule();
-            u ? n(r) : t(e);
+            o ? i(n) : e(t);
         };
-        const step = (e, r) => {
-            let t;
+        const step = (t, n) => {
+            let e;
+            // The body is on the stack between these brackets: flush() is
+            // refused inside (FLUSH_IN_ACTION, scheduler.ts).
+                        enterAction();
             try {
-                t = r ? i.throw(e) : i.next(e);
-            } catch (e) {
-                return done(undefined, e, true);
+                e = n ? o.throw(t) : o.next(t);
+            } catch (t) {
+                exitAction();
+                return done(undefined, t, true);
             }
+            exitAction();
             // A rejected iterator result (async generators) means the error already
             // escaped the generator body — it is completed, and throwing back in
             // would just reject again forever. Settle instead.
-                        if (isThenable(t)) return void t.then(run, e => done(undefined, e, true));
-            run(t);
+                        if (isThenable(e)) return void e.then(run, t => done(undefined, t, true));
+            run(e);
         };
-        const run = e => {
-            if (e.done) return done(e.value);
+        const run = t => {
+            if (t.done) return done(t.value);
             // Thenable assimilation can itself throw synchronously (a `then`
             // getter, or a `then()` method that throws — #2918). Match `await`
             // semantics: the failure is thrown back into the generator at the
             // yield point (catchable there); if uncaught, step()'s guard settles
-            // the action so its iterator never leaks in the transition. The
-            // settled flag implements A+ 2.3.3.3.4.1: a throw after the thenable
-            // already called a callback is ignored.
-                        let r = false;
+            // the action. The settled flag implements A+ 2.3.3.3.4.1: a throw
+            // after the thenable already called a callback is ignored.
+                        let n = false;
             try {
-                if (isThenable(e.value)) return void e.value.then(e => {
-                    if (r) return;
-                    r = true;
-                    restoreTransition(o, () => step(e));
-                }, e => {
-                    if (r) return;
-                    r = true;
-                    restoreTransition(o, () => step(e, true));
+                if (isThenable(t.value)) return void t.value.then(t => {
+                    if (n) return;
+                    n = true;
+                    inTransaction(r, s, () => step(t));
+                }, t => {
+                    if (n) return;
+                    n = true;
+                    inTransaction(r, s, () => step(t, true));
                 });
-            } catch (e) {
-                if (r) return;
-                r = true;
-                return void restoreTransition(o, () => step(e, true));
+            } catch (t) {
+                if (n) return;
+                n = true;
+                return void inTransaction(r, s, () => step(t, true));
             }
-            restoreTransition(o, () => step(e.value));
+            inTransaction(r, s, () => step(t.value));
         };
+        // The first slice's writes are carried by the tick's scheduled flush;
+        // the slice itself asks the action's question (its guesses are stamped
+        // at the write).
+                joinFuture(r);
+        const u = question;
+        setQuestion(s);
         step();
+        setQuestion(u);
     });
 }