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>

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>

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.