Solid 2.0 async system design choices

[dangkyokhoang]

I want to ask some questions about the design choices that were made in Solid 2.0 regarding async resources.

1. From https://github.com/solidjs/solid/blob/next/documentation/solid-2.0/05-async-data.md, "isPending may also be used outside a Loading boundary when the expression only reads upstream state that cannot itself be not ready." Why isPending cannot be used outside a Loading boundary for async resources? Shouldn't isPending be able to be used anywhere in the tree? The below pattern is probably not uncommon - which always renders a button to refresh the resource - but doesn't work as expected:

<Errored fallback={(err, reset) => (
  <>
    <div>{String(err())}</div>
    <button onClick={reset} disabled={isPending(data)}>
      Reset
    </button>
  </>
)}>
  <Loading fallback='suspended tree that depends on `data`'>
    <div>Data: {data()}</div>
  </Loading>
  <button onClick={() => refresh(data)} disabled={isPending(data)}>Refresh</button>
</Errored>

Workaround: try catch isPending to prevent it from throwing NotReadyError

export function isPendingSafe(fn: () => any): boolean {
  try {
    return isPending(fn)
  } catch (error) {
    return error instanceof NotReadyError
  }
}

2. Why isPending is designed to cause render errors, instead of just returning true or false when the resource is pending or not? The below code is expected to render the button, even if data fails, since nothing breaks, but actually renders Errored.

<Errored fallback='Errored'>
  <button onClick={() => refresh(data)} disabled={isPending(data)}>
    Refresh
  </button>
</Errored>

And when I want to disabled the reset button in Errored fallback, the below doesn't work:

<Errored fallback={(err, reset) => <button onClick={reset} disabled={isPending(data)}>Reset</button>}>
...
</Errored>

Workaround - not what I want but at least doesn't crash the app - is to use <Loading on> to discard the Errored state:

const [track, update] = createSignal(0)

<Loading fallback={<div>Loading...</div>} on={track()}>
  <Errored fallback={(err, reset) => <button onClick={reset} disabled={isPending(data)}>Reset</button>}>
  ...
  </Errored>
</Loading>

I couldn't find a way to safely subscribe to async data inside Errored fallback. The isPendingSafe above doesn't work because reading reactive values create dependency links which drive error state transitions directly without calling fn again.

3. isRefreshing has been removed in this commit 52255dc, then how do I tell whether the function in createMemo is being recomputed as the result of refresh(resource)? I think a common use case for async createMemo is to use a separate query client / cache store like createMemo(() => client.query(userApi)) instead of a direct createMemo(() => fetch(userApi)). To integrate such query client with Solid's async system, I need to check isRefreshing() (and isResetting() - if available) in the createMemo function to decide whether to return cached data or to refetch. IMHO it's unlikely that one relies on createMemo for global state management / caching in bigger applications.

The changelog mentions: "refresh() is an action that invalidates an explicit refresh target; it should not expose ambient phase state to pure computations." Why is the function in createMemo considered pure computations? It likely interacts with external sources (that's why it's async) which means it's not pure. And "User-visible mutation or retry intent should be modeled with actions and optimistic state", but modeling refresh intents with optimistic states is probably more complex if the async resource is used in multiple places in the tree.

The below pattern is common with query clients and would be more complex to implement with createOptimistic/createOptimisticStore:

// Header.tsx
const user = createMemo(() => client.query(userApi));
// renders user info

// UserProfileEdit.tsx
const user = createMemo(() => client.query(userApi));
// renders user info and edit form
// on mutation start, optimistically updates query client cache, which causes Header to re-render

The workaround for my case is to use dependency tracking between computations, to rule out known pathways that causes recomputations, and then isRefreshing = deepStrictEqual(oldDeps, newDeps), but that's not ideal I think.

It looks to me that those design choices result in somewhat... React-ish code - rules of primitives and dependency tracking. I'm new to Solid though so I might be missing something.

[joodaloop]

Yeah, I don't like the decision to force pending state management into only <Loading> and isPending(), especially since isPending only works within a <Loading>?? If I understand this correctly, it makes it impossible to track first load outside of the Loading's fallback component?

[dangkyokhoang]

I've updated point 1 with a workaround that makes it possible to track loading status outside of Loading. Still can't find a way to track loading inside Errored fallback though.

[joodaloop]

I still think this kind of functionality shouldn't need workarounds...but maybe I'm missing the big picture

[brenelz]

The question in this case is why wouldn't the button go within the boundary? isPending is not for initial load.

You probably wouldn't want to show the refresh button before data has loaded?

<Loading fallback='suspended tree that depends on `data`'>
    <div>Data: {data()}</div>
</Loading>
<button onClick={() => refresh(data)} disabled={isPending(data)}>Refresh</button>

[dangkyokhoang]

Well, that's just an example. I mean we need to duplicate the code in Loading fallback and Show when isPending to show a placeholder while loading, initially or subsequently, which makes it more verbose, less readable.

This pattern for example, a save button in the header and a form below:

const App: Component = () => {
  const [todos, setTodos] = createOptimisticStore(fetchTodos, []);

  const save = action(function* (text: string) {
    setTodos((prev) => { prev.push({ id: -1, text }) });
    const saved = yield saveTodo(text);
    setTodos((prev) => { prev.at(-1)!.id = saved.id });
    refresh(todos);
  });

  ...

  return (
    <>
      <button form="form" type="submit" disabled={isPending(() => todos.length)}>Save</button>

      <Loading fallback={<p>Loading…</p>}>
        <form id="form" onSubmit={onSubmit}>
          ...
        </form>
      </Loading>
    </>
  )

But that doesnt work, you need to use Loading which makes it more verbose:

<Loading fallback={<button type="submit" disabled>Save</button>}>
  <button form="form" type="submit" disabled={isPending(() => todos.length)}>Save</button>
</Loading>

<Loading fallback={<p>Loading…</p>}>
...
</Loading>

Or this, a header with loading indicator:

<header>
  <Show when={isSomePending(memos)}>
    <LoadingIndicator />
  </Show>
</header>

...

<main>
  <RegisterAsyncMemo memo={list} />
  <Loading>
    Suspended list: {list()}
  </Loading>
</main>

Or simply this, showing placeholder while loading:

<Loading>
  Suspended list: {list()}
</Loading>

<Show when={isPending(list)}>
  <Placeholder size={size} />
</Show>

Instead of:

<Loading fallback={<Placeholder size={size} />}>
  Suspended list: {list()}

  <Show when={isPending(list)}>
    <Placeholder size={size} />
  </Show>
</Loading>

[joodaloop]

Yup exactly, it makes it hard to show non-fallback loading indicators. I understand that Loading is the way to handle loading in a composable-ish way, but it would be nice to have access to "this value is loading" anywhere in the tree.

[ryansolid]

I see some bugs here that probably confusing the design a bit. 2. is most definitely a bug. IsPending shouldn't be erroring out, and only is responsible for propagating NotReady in the initial case. That being said both 1 and 3 probably deserve a more detailed response.

1. Is tricky mostly because we want it to be able to guard and we want it to work with SSR/Hydration. Streaming chunks require that partials be in their final state on the server before hydration so that it matches. For SSR means we only have 2 choices, we either render/hydrate isPending as false always initially, or we hold sending the chunk until it has settled. true isn't valid because it could toggle back to false at any time before/after hydration of that part which could impact what is rendered and how hydration would line up. Where we sit today we don't have the means to create boundaries smaller than like <Loading>.

However, false doesn't properly guard things like inputs that want to be disabled until ready. So the only real choice here is to how the boundary initially. I know it seems weird to let streaming/hydration to govern decision here but it is the only safe single solution. I played with having different options to have different behavior but they were all really similar so naming, choosing when to use each wasn't really clear. I think the current position is the best default. Can we do better here? Looking for options.

3. From a graph perspective our approach to async read propagation is that isn't a side effect. It is just an async node in the graph. It is in the middle of the graph rather than at the end. I think the biggest take away here is the difference between read and action.. propagation and process.

There needs to be some educational content around this. It is really as primary as UI = fn(state) sort of thing. That in itself only describes the propagation side.. the GET/read side. The whole other half of the equation isn't represented. And its super important in understanding what isPending is.

The sequence of events was we fixed refresh to be shallow to the point of just working on specific primitives.. leading to having refresh thread through normal propagation (it used to do something weird like ahead of normal flush). This required weaving flags in which complicates things unnecessarily. Like how are we supposed to know why nodes are re-running.. At which point isRefreshing seemed wrong.. like yes you could want to know that a refreshing process is running but it isnt a property of propagation.

Basically the key to propagation side is that it is always a snapshot of untorn state.. it where all our signal rules take effect. Every node runs once and in order, etc... which means it only knows that it is consistent not why. There is no time.. It could be updated because of 200 distinct changes for 200 distinct reasons but none of that matters. It just needs to produce the right results exactly once at a node level. isPending is only telling you that the node isn't there yet.

Asking why has no business here. If you have some sort of process.. feel free to reseed an external source outside the system, clear a cache.. even use refresh to re-propagate on resolution but keep that stuff outside. If you want to know the status of your process use optimistic state. I realized that when resetting error boundaries. I'm at the point I'd call any function even state setters actions.. updating a value, resetting an error boundary, trigger refresh of part of the graph are all parts of actions.. the other half.

isRefreshing was designed to thread through the propagation but that isn't great. Once you remove that case it either means doing some sort of out system update before triggering refresh or adding some optimistic state to reflect the state of the process in the UI.

Using your example. A query client probably should subscribe to its key, or at minimum the invalidation of the cache can be pushed to where the call to revalidate. Ie clear cache before triggering refresh.