Redesigning createAsync to suspend when it reads from a pending signal (+ bonus context API)

[NawfelBgh]

Hello,

I think that this discussion should better has its place in core SolidJS repo, but I'm posting it here since this is the current home for the createAsync primitive.

I think that it makes more sense for createAsync to suspend the execusion of its callback if it tries to read from an async signal that is still pending, and to only retry again once that signal's value is available.

Here is a code example:

import { createAsync } from '@solidjs/router';
import './App.css';

async function sleep(timeMs) {
  await new Promise((resolve) => setTimeout(resolve, timeMs));
}

function App() {
  const s1 = createAsync(() => sleep(100).then(() => 1));
  const s2 = createAsync(() => {
    console.log('before');
    const v1 = s1();
    console.log('after', v1);
    return sleep(100).then(() => v1 + 1);
  });
  return <div class="App">hello</div>;
}

This code currently prints:

before
after undefined
before
after 1

where as I think that it makes more sense for it to print:

before
before
after 1

---

The behaviour I propose resembles how SolidJS works in suspense contexts. Which reminds me of an API that I thought was missing in SolidJS when I read the docs: The thing being that the only way to provide values for contexts currently in SolidJS is via the Context.Provider component. Where as I think that SolidJs should offer an API to provide context values without involving components. I propose therefore that SolidJS should offer a function (let's call it withContextValue) which behaves like:

  withContextValue(MyContext, value, () => {
    assert(useContext(MyContext) === value));
  });

Such an API may turn out to be necessary to make createAsync suspend as suggested here, without it requiring us to
reach for components just to be able to use suspense contexts.

I'm into something. Right?

[ryansolid]

That's the intended behavior in 2.0 but it is basically not possible the way we work today. I mean that is basically the primary async goal of the Solid 2.0.

[NawfelBgh]

@ryansolid I'm glad to hear that this is the direction you envision for Solid 2.0.

I had some more thoughts about this problem space:

TL;DR: In Solid 2.0, createMemoshould suspend too when it reads from a pending signal.

Let's say that Solid 2.0 implements createAsync which returns a signal object. How would you create a computation that uses the value of that signal? Before this proposal I used to think that we needed createAsyncMemo (like useAsyncMemo in React world). But then, I realized that createAsync is capable in itself of playing the role of createAsyncMemo, hense this proposal.

Now I realized another thing: Since createAsync returns a signal object that has the same interface as any other signal, I think that createMemo should be able to use such signals transparently suspending whenever it reads from signals that are in pending state. And when createMemo's callback is suspended, the derived signal should be set in pending state, until createMemo is notified of a change and is able to execute its callback to completion.

The idea here is that we shouldn't having two types of signals, signals that always have values and others that may be pending or initialzed.

---

This makes me have some questions:

TL;DR: In Solid 2.0, should a signal created with createAsync and createMemo keep its old value while a new value is being calculated? And should all signals have a signal.pending property? (simple signals like anySignal.pending can be defined to always be false, I guess)

I did not form a strong opinion about any of this yet. I see that, currently, signals created with createAsync keep their value while a new one is being computed. I see also that you decided to not expose the users of createAsync to resourceData.loading and resourceData.error (from createResource). I guess that a case can be made for exposing the loading signal (maybe under a different name: pending/unresolved/...).

---

Last thought, I think that with async integration in Solid 2.0, an API for creating signals that are not initialized can come in handy:

const [read, initOrWrite] = createUninitSignal<T>();

[ryansolid]

Yeah it is more that any downstream signal could be pending or require fetching the latest value so it doesn't make sense to hang them off it as much. Early implementation does have a .loading on everything but I'm not sold.

I don't think it is about initialization though. It is any time it is in flight. I suppose there may be an argument for first time initialization but in general most of the mechanism is around just knowing whether stuff is pending or not. And it needs to play into the rest of the rendering system as well. This has big impact on scheduling of effects.

If you have a particular interest here we probably should get this kind of conversation into the reactivity working group. I've let that go cold the last year or so but it will be picking up again.