Memoized functions (client side equivalent to query remote functions)

[phi-bre]

I am proposing a new primitive (or an enhancement to the upcoming resource API) that enables on-demand, async, memoized, and reactive client-side data fetching.

The goal is to bring the developer experience of SvelteKit’s remote functions (specifically the caching/sharing mechanism) to client-side logic, allowing shared state across components without the limitations of setContext or the complexity of manual cache invalidation.

---

Proposed API

The usage would look similar to a query remote function but designed for client-side logic (e.g., inside .svelte.js files).

Option A: String Key

import { online } from 'svelte/reactivity/window';
import { memoize } from 'svelte/reactivity'; // Hypothetical import

export const getTodos = (id) => {
  return memoize(`/todos/${id}`, async () => {
    // Track svelte signals:
    if (!online.current) return null;
    
    // Track signals after awaits (e.g. react to remote function refreshes)
    const user = $derived(await getUser());
    if (!user) return null;
    
    const todos = fetch(`/api/todos/${id}?user=${user.id}`).then((res) => res.json());
    
    // Since they have their own lifecycle, maybe even have an on/off notifier:
    $effect(() => {
      // e.g. start websocket connection
      return () => {
        // e.g. cleanup websocket connection
      }
    });
    
    return todos;
  });
}

Option B: Schema/Auto-key (Remote function style)

export const getTodos = memoized(z.string(), async (id) => {
  // ...
})

---

Motivation

Currently, sharing async state in and outside the component tree is friction-heavy. While setContext / getContext is the standard solution for SSR-safe shared state, it imposes strict limitations in an async environment:

1. Component coupling: It must be called inside a component tree.
2. Async blocking: It cannot be called after an await expression.
3. Function boundary requirements: To maintain reactivity, state must be passed via getters (e.g., setContext('key', { get value() { return signal }})).

This proposal asks for a primitive that allows data to be defined globally (or in shared modules) and consumed locally, with the framework handling the lifecycle and cache sharing.

---

I have attempted to implement this pattern in userland, but I have hit specific roadblocks regarding how Svelte 5 handles reactivity across async boundaries.

1. The "Async Gap" in .svelte.js files

In Svelte components, $derived(await ...) magically handles signal tracking across await boundaries. However, replicating this inside standard .svelte.js functions is inconsistent.

Although using $derived inside a function technically compiles, the behavior is flaky. Reactivity often fails to track signals correctly if the execution involves complex async flows, or it requires multiple signal changes to "wake up" the tracking.

See reproduction in Playground

2. $effect.root does not support async

To memoize a resource that might be called outside a render effect (e.g., in an event handler), we need to create a root scope using $effect.root. However, $effect.root cannot contain async execution.

---

I am aware of the upcoming resource primitive in #16960. While exciting, the current design seems to rely exclusively on manual invalidation (.refresh()).

If I have a resource that depends on other resources, I have to manually cascade .refresh() calls. Ideally, the resource should track signals (including other resources) used in its "run" function and automatically re-run when dependencies change, keeping the value up to date without manual intervention.