A simpler way of suspending components

[lxsmnsyc]

As we know, Suspense (originally a React component) is a Component for displaying fallbacks when a certain resource was suspended. createResource provided an API to perform data-fetching while coordinating with the nearest Suspense boundary to display fallback. This is ideal however there are libraries or snippets that provide a completely different strategy for data-fetching. For instance, stale-while-revalidate-based data-fetching libraries (e.g. react-query or potentially, a Solid port of SWR) tend to show the previous data for a certain amount of time until the new data arrives, otherwise it shows the fallback. This is different from createResource which is a network-first strategy.

Currently to circumvent this problem we can wrap the library or the strategy into a createResource but that leads to unnecessary overhead or memory leak.

React provided a simple way of suspending components which is for Suspense to catch a thrown promise. The feature is flexible enough to be called across certain contexts, but isn't direct enough to skip error boundaries (which is what createResource excels at).

A proposal for this API is to provide a function (let's call it suspend). suspend receives an accessor that returns a Promise result (Extra: please see #608), in which it keeps track for the entire Suspense lifecycle. Suspense will keep all of the results (or just track them from their respective components) and reacts to the state of the results to display the fallback indefinitely. Here's how it would look like

const [data] = createResource(...);

suspend(data);

Since Solid's Suspense is optional for createResource, calling suspend is optional too.

suspend is also useful for the third-party libraries or snippets as a means to communicate with Suspense boundaries. It is also simple and flexible enough for users to write their own resources. This potentially allows creation of global resources (which Solid lacks currently) which allows components to share the same instance of resource.

const globalResource = createGlobalResource(fetcher);

function ComponentA() {
  suspend(globalResource);
}

function ComponentB() {
  suspend(globalResource);
}

[ryansolid]

I don't understand the proposal mostly that I don't know what things like createGlobalResource are. Is suspend a read? Like is it more or less:

createComputed(data)

createResource doesn't care what the promise is.. it doesn't even need to be a promise. But we always need to track so I figured any SWR like behavior would happen in the fetcher. Like:

function createQuery(key, fetcher) {
  return createResource(key, (key) => {
     const v = cache[key];
     const p = fetcher(key);
     if (v) return v;
     return p;
  })
}

I've never looked at these libraries but this was roughly what I was thinking. createResources internals are quite complicated to support transitions. They contain computations to trigger things on read etc so they don't lend to be global without managing disposal.

[lxsmnsyc]

I apologize if I can't get the idea through (I'm bad at explaining stuffs in writing). suspend isn't a computation, it's just a way to notify Suspense that it is to receive an accessor (a resource) and to make Suspense track for its current status. I would assume createResource currently has a similar internal mechanism with suspend, although that we are just exposing the said mechanism into a function like suspend.

createGlobalResource is a metaphor for the concept of resources in React such that resources in there isn't tied to any components at all. Components just read these resources arbitrarily and the resources provides a way to communicate with the components' suspense boundaries. The benefit of a global resource is to keep and maintain a single cache for the fetcher and helps share it across components (and non-components, in general). It also potentially allows users to preload the resource outside the component (for whatever motivation).

[ryansolid]

Solid notifies Suspense by reading resources under Memos, Computeds, and first run Render Effects. It looks up their owner tree until it finds the Suspense Context provider and registers the internal promise. So I think writing createComputed like I did is what you are describing. The important part is the boundary isn't the owner of the resource but the owner of the context that reads it.

As for createGlobalResource I'm not sure it's a thing here. As I said resource internals are complicated that they should be created under a reactive context. Could manage createRoot yourself and disposal. Any reason this couldn't be just a Context provided resource? Disposal is all taken care of. I don't understand the memory leak angle. Any component can just useResource and do it. And preloading well not sure the API but that is a way of interacting with the cache. I'm not sure it has anything to do with the resource.

I was trying to reconcile this before in my head when I was trying to figure out the role of resources versus caching and I realized these are probably separate things. You can have multiple resources read the same cache location. Tying these together is weird if the key can change. Tracking is a large part why we execute the resource and for preloading that isn't the case. Truthfully I don't have the solution and it's highly relevant to the next features being developed for Solid Start. So I'm interested in working that out.

[lxsmnsyc]

The only core ideas for exposing the mechanism are:

• skip the overhead of using createResource to communicate with Suspense
• provide a simpler way for 3P libraries or user-land to create their own resource definition, akin to React's throw promise;.

More or less, I feel like I needed to provide a real-world scenario or just a simple case scenario where this would be a win.

[ryansolid]

Your examples looked like you were passing the resource to suspend which was my confusion. Are you suggesting just passing a promise to suspend? That could work in a simple case and is less overhead because we remove the read... it becomes like the read.

[lxsmnsyc]

This discussion can be closed now, sorry for the misconception