The design of createResource and Suspense behavior

[lxsmnsyc]

This thread is more on discussing the current design of createResource and Suspensebehavior and in light with the recent article @ryansolid made.

Current design

Pros

• Reading resources and the suspending mechanism triggering is non-blocking on both rendering and the computations, which means a component (and it's children) cannot be interrupted from rendering while showing the fallback UI.
• Suspending is based on where the resource is accessed, not where it was declared.

Cons

• Data isn't guaranteed initially.
  • The whole pending === undefined is flawed. We cannot rely on it for checking pending states, because there can be some intent where the user's implementation actually returns undefined for the fetcher.
  • Passing a resource to a prop and that value being drilled means we lose track of which prop is actually a plain signal, a plain value or a resource, and once we lose it, we can never check for the resource' states.
  • Most of the time users would resort to using Show just to make sure the the data is guaranteed to be there, which then kills the non-blocking aspect of things.
  • The UI inside Suspense is no longer a "success UI" but in a weird zone of "pending" and "success" since the whole stuff still runs while the data are pending.
  • Also minus points for being unfriendly to TypeScript.
• The rest of the properties do not trigger Suspense.
  • Checking for the status instead of the resource before accessing the data just crumbles.

React's design principle on createResource' data

Assume that the "throw promise" behavior is implemented in the resource callback.

Pros

• Data is always guaranteed.
  • We don't have to check for any states. We can always assume that the success UI will always have the resolved values. Show is also dropped as a dependency for most people.
  • No need to worry about backtracking props/callbacks to identify if they are depending on a resource.
  • TypeScript friendly.

Cons

• It is blocking and re-evaluating.
  • For the value to be guaranteed, it has to re-evaluate the nearest owner/listener. The bad stuff can occur when there are side-effects that will re-run unintentionally. The most impacted aspect of this is around createEffect.
• The owner cannot handle it once the resource is accessed outside of it.
  • setTimeout might be a victim.

Result<T>

Instead of data(), we only have data.value and data.status

Pros

• Non-blocking.
• TypeScript friendly
• No need to worry about where it is called.
• Flexible enough to maybe not require a Suspense to trigger
• Flexible enough to maybe not require an ErrorBoundary to trigger.

Cons

• Too much status checks
  • It's honestly both a pro and a con.
• Lack of Suspense and ErrorBoundary means
  • we don't even know if we can consider specifically when to serialize it's data.
  • Fallback UI is no longer scalable.

Other thoughts

There might be other patterns, pros and cons that I have missed, feel free to comment.

[jer3m01]

Result<T>

Small twist on Result<T> instead of having data.value and data.status we could have:

• data() for the value
• data.status as the status

This keeps all the same pros/cons as the original but has a shorter more familiar syntax to the current Solid createResource(). This is still Typescript friendly to keep type narrowing.

Personal thoughts

I much prefer the non blocking option, the cons of blocking put too much on the developer to avoid unwanted side effects.

Too much status checks

This doesn't seem to be too much of a problem, our current resource primitive also requires this and a wrapper can easily be made to handle them and make it blocking. In effect giving us both behaviors as needed.

Lack of Suspense and ErrorBoundary means

What exactly does this mean? Is this a problem on Solid's end or the developer?

[lxsmnsyc]

What exactly does this mean? Is this a problem on Solid's end or the developer?

I think that it is redundant to have both a Suspense and a mandatory status check, which is basically the con of the current design.

[katywings]

I need to think more about it, but just one quick thought: isnt Result<T> basically the same coloring as Promise<T> which Ryan is trying to avoid?

[lxsmnsyc]

The thing with Result<T> is that it might just be too explicit, but the nice thing is we can opt into a React-like suspense behavior, but still get the niceties of the Result<T> specially in code where there is no owner.

[bigmistqke]

This everything can suddenly throw everywhere idea makes me a bit anxious. I think it works better in a context like react, where reactivity is locked into the component, and where re-running is baked into the philosophy.

I was thinking, what if we make the throwing behavior explicit?

function Comp(){
   const [resource] = createResource<{id: string}>(() => ...)
   return (
      <Suspense>  
         {resource()?.id}
         {use(resource).id}
      </Suspense>
   )
}

• Without use we have the same behavior as before:
  • Resource is initially undefined (or some unresolved-symbol, if we want allow undefined as a return-type)
  • Use checks to see when it is resolved
• With use we throw on unresolved Resource
  • Throws to the nearest Suspense, derivation, ...
  • Get nice types

Plus

• Explicit
• Get control when it throws and (more importantly) when it does not throw

Con

• Verbose
• Having to think about where you want this thing to be thrown (do you want to pass the resource or resolve it directly at the base?)

[lxsmnsyc]

Having explicit suspense points to the Result<T>, but we have to address the SSR side where we rely on detecting if resources are read or not.

[katywings]

I think a lot of this unnecessary throwing can be prevented if we get an isLoading or even isReady. People who wanna prevent the throws could then just use the good ol <Show> pattern like this:

function Comp(){
   const data = createAsync<{id: string}>(() => ...)
   return (
      <Show when={isReady(data)}>  
         Don't worry...
         About a {data()}...
         Cause every little {data()}...
         Is gonna be alright!
      </Show>
   )
}

[ryansolid]

Yeah I thought about this for a bit and if you need to null check the throwing it sort of defeats the point.. you could just null check. Which is why I think the reverse makes more sense... like the latest or isLoading guards because in those cases you'd need to guard anyway.

[katywings]

Gotcha, yeah I saw the isReady checks more as a optional way to squeeze out performance, basically everything works without them, but you can use them to reduce the affected tree sizes of the throws. Same is also possible with isLoading ofc 👍.

[Brendonovich]

I really like the throwing async design. Doing away with type narrowing is a huge benefit, and throwing granularly along makes a lot of sense to me.
I think describing it as 'blocking' is a bit heavy handed, since I can think of a number of cases where it would be less blocking than the current implementation thanks to Show being less necessary, but it would be blocking and re-evaluating for derivations and the pure half of effects - I don't think that's a problem though.
The case of stuff like setTimeout is interesting, I'm not sure what should be done about that.

[ryansolid]

Thanks @lxsmnsyc for laying out this discussion. I agree that there are 3 approaches here but I think they are slightly different. The last approach (Result) I think is always viable regardless as long as people don't opt into the primitives. Like you don't need createResource or createAsync to do anything. You just avoid them and then you are fine until you hit SSR. Fixing for typescript though I consider additional consideration. Like fixing it here with .value is inconsistent with every other primitive. I don't see that likely happening.

Similarly I think splitting the pure/tracking parts effects is pretty much a must have. We would be so much better even today if we did that. So I'm going to approach this assuming some other changes have happened. I think it changes perspective on things.

My Pro/Cons are a bit different I suppose.

1. Specific Primitive Non-Throwing (An update on what we do today)

Introduce createAsync. Remove the .error, .status etc fields to not encourage the status checks. Improve async status propagation.. ie only Suspend in the front half of effects so reading derived doesn't suspend. There will be isLoading helper that can identify if anything being read is async. The only remaining sub field might be .latest a way to opt out of all this behavior.

A ton of the flaws of the current system are addressed while leaving things mostly the same.

Pros

• Reading resources and the suspending mechanism triggering is non-blocking on both rendering and the computations, which means a component (and it's children) cannot be interrupted from rendering while showing the fallback UI.
• Suspending is based on where the resource is accessed, not where it was declared.

Cons

• Data isn't guaranteed initially.
• Most of the time users would resort to using Show just to make sure the the data is guaranteed to be there, which then kills the non-blocking aspect of things.
• The UI inside Suspense is no longer a "success UI" but in a weird zone of "pending" and "success" since the whole stuff still runs while the data are pending.
• Unfriendly to TypeScript.

Variation

There is a sub option to have only lazy memos. If done we can avoid even having createAsync and just use createMemo. However I think people could accidentally cause waterfalls way too easily that way. A simple if statement could defer fetching. It is attractive as it could get rid of the need for a dedicated async primitive at all since we don't have status fields.

2. Specific Primitive Blocking (As described in my article)

Again introduce createAsync, isLoading except this time things throw along the graph.

Pros

• Data is always guaranteed.
• We don't have to check for any states. We can always assume that the success UI will always have the resolved values. Show is also dropped as a dependency for most people.
• No need to worry about backtracking props/callbacks to identify if they are depending on a resource.
• TypeScript friendly.

Cons

• Async (and thus everything) is held to the rules of reactivity without exception. This means that the same gotcha people hit when learning Solid is the one rule here as well. Ie reading in setTimeout etc.. Basically all places you can retain reactivity are necessary here without guards.
• Because we don't block at a component level like React it is possible for event handlers to throw. You should control for things not being read, ie Suspense around those zones.. but people will hit this and it might be intermittently. That being said they would have needed a null check here before so that doesn't really chage.

3. Screw this stuff

No async primitives or maybe offer one if we want to make it more convenient instead of doing it in userland.

Pros

• Non-blocking.
• No need to worry about where things are called.
• Less concepts in core library

Cons

• Data isn't guaranteed initially.
• Too much status checks
• Lack of Suspense and ErrorBoundary means we don't even know if we can consider specifically when to serialize data. Need other way or a simple primitive to manage Streaming SSR.
• Fallback UI is no longer inversion of control.
• Async isn't derivable so no concurrency all async needs to be hoisted (good thing to do anyway)
• Still unfriendly to TypeScript.

---

Anyway I think it isn't too hard to picture the 3rd option, have that always be an option regardless.. I need to prototype the second option more I think to actually make the case for it. It has the potential to do things we haven't seen before, and need to understand if the fear is unwarranted. The first option is also perfectly fine if updated to address its current challenges.