Allow components to return Promises (maybe using lazy)

[titoBouzout]

Came across a component on which I need to run a Promise so I was wondering, if it would be possible to return Promises from the component.

This seems to be possible already using Suspense
https://www.solidjs.com/tutorial/async_suspense?solved

The problem of this is that when you are not importing a component, inlining it requires a lot of boilerplate: (courtesy of @mdynnl )
https://playground.solidjs.com/?hash=101461053&version=1.3.9

Ideally, one would, may like to do the following :

import { render } from "solid-js/web";

const HelloWorld = () => {
  return  new Promise((resolve) => {
    setTimeout(() => resolve(<div>Hello World</div>), 2000);
  });
};

render(() => <HelloWorld />, document.getElementById("app"));

A suggestion from @mdynnl is to use lazy, although I dot not have the understanding necessary to know about the implications
https://discord.com/channels/722131463138705510/722349143024205824/955913065809989642

Thoughts? Thanks!

[lxsmnsyc]

I'm personally against this. If we want this, this may negatively impact createComponent because most of the time, majority (I'm not saying all) won't be using this pattern. Also, promises aren't really side-effect proof, so if ever we have asynchronous logic, it's better to always use createResource for consistency.

[atk]

Why not have a Promise trigger a components' state instead of abusing suspense here?

const EventuallyHelloWorld = () => {
  const [message, setMessage] = createSignal<JSX.Element>(null);
  new Promise((resolve) => {
    setTimeout(() => resolve(<div>Hello World</div>), 2000);
  }).then(setMessage);
  return message
};

Using lazy would only make sense if you need Suspense in order to manage Fallbacks.

[atk]

If message was a valid JSX.Element, this is already a component.

[mindplay-dk]

I've looked at all the examples and I don't understand what I'm supposed to do here. 😕

I have a component that needs to fetch a couple of resources - I want the app to suspend and display a loader meanwhile.

I expected suspense would be a generic facility to suspend and display a loader while a component is getting ready?

Do I understand correctly, that the suspense feature and lazy are designated specifically for lazy-loading with dynamic import?

While it's not difficult to build your own loaders, it just seems odd that this feature is limited to waiting for loading a component - it's not too uncommon, if you load a component, the component also needs to load some data before it's ready to render. So you'll need your own loader inside the component to replace the loader displayed at the suspense boundary, and so on.

Besides needing to add extra complexity for loaders everywhere, I believe this is what leads to the ugly "multiple spinners popping in and out" you typically see when React apps start up.

What I thought suspense would give me is a single boundary for a loader that displays until the entire tree is ready - whether that means loading components or fetching data, or really just resolving anything that requires a promise, why should it matter?

It's a bit disappointing, and it seems like this might be an area where we could drastically improve over React?

[ryansolid]

createResource is what you are looking for. It's a generic Suspense triggering mechanism. Suspense does what you think it should if configured properly. I think there is a misunderstanding here.

[mindplay-dk]

createResource is what you are looking for. It's a generic Suspense triggering mechanism.

Oh it is!

The suspense tutorial page does mention createResource, but makes it sound like this is an alternative and not like those feature would work together.

The resources tutorial page does not make that clear - the word "suspense" does not figure on that page.

Perhaps the resources example should include a suspense boundary? Or perhaps a separate example could show these features working together? I've read both the API reference and tutorials - I could have missed it, but I didn't find an example of these features working together.

[ryansolid]

https://www.solidjs.com/tutorial/async_transitions is probably the best combination use. But you are right this usage in the tutorial isn't really even the recommended pattern.