1 of 27

Why all the Suspense?

Docs and information available at www.solidjs.com

2 of 27

Who am I?

3 of 27

Why Suspense?

4 of 27

5 of 27

Phantom Notifications

It can persist in more annoying ways than something that can be solved with a reload. In an early React Talk, “Rethinking Web App Development at Facebook”, Jing Chen recounted a story of how Facebook Messenger had this bug that kept on coming back. They’d fix it, sometimes painstakingly so because of how complicated the synchronization logic had gotten around messenger at the time which was still embedded as part of the main Facebook app.��The bug was that people would often get a phantom notification showing they had a message when they had already seen/cleared all their messages. A seemingly simple annoyance, but as a user you’d think you had a new message and didn’t. Having this happen multiple times a day meant you didn’t trust that you had new messages and not receive them, or leave the more obsessive user full of disappointment and anxiety.��This seemingly harmless bug was so annoying for users that whenever Facebook launched new unrelated features it was overshadowed by the demand that this be fixed. Not being able to depend on the software you use everyday is crippling

6 of 27

React: 0 0 0

Vue 3: 1 2 0

Svelte: 1 0 0

Solid: 1 2 2

7 of 27

Tearing

8 of 27

9 of 27

Show Placeholder
Stay in the Past
Show the Future

Async Consistency

10 of 27

What is Suspense?

11 of 27

What Suspense is Not

12 of 27

Reads are Key

const [data, { refetch }] = createResource(

() => fetchUser(`/api/users`)

);

return <Suspense fallback={<div>Loading...</div>}>

{JSON.stringify(data())}

</Suspense>

The common ground in all Suspense implementations is mechanism is based on the reading of a future async value, not on the fetching. This is super important to understand as it both enables us to hoist data fetching up as high as we need and it gives us inversion of control. You can approach Suspense boundaries as a designer rather than a developer. Consistency zones are based on your User Interface. It makes the system resilient to change as you build your layouts and as more async functionality comes in you have the same loading experience by default. ��This is also why how you read is important. You need a mechanism, maybe even a data primitive in order to register these reads. Obviously there are promises. But Promises execute once, you need more of a Promise factory that can be cached. But in Solid we already have something that already works like this. Signals. They already multi-value and intercept reads.

In our case we call these special async Signals, Resources and they along with Suspense boundaries are the underlying pieces behind everything I will show today.

13 of 27

Showing Placeholders

14 of 27

More than Data Fetching

15 of 27

Handling Errors

16 of 27

Out of Order Streaming

17 of 27

18 of 27

2. Staying in the Past

19 of 27

Introducing Transitions

20 of 27

How Transitions Work

21 of 27

Important things to know about Transitions are they impact the whole application. Suspense informs that the resource impacts the view, but the mechanism for Transitions ultimately is global. But we do still have some control. One design that is present in React that we also adopted in Solid is the idea that only existing Suspense boundaries Suspend. New ones always go to fallback. This is actually quite convenient as we still have power to break up our views in a reasonable way without being stuck in a single mode. More so it means that Transitions can be built into the underlying system, like the router without taking away the ability for the end user to control what holds in the past and what hides consistency.��Tab Demo with Nested Suspense

Start: https://playground.solidjs.com/anonymous/4745e3b9-ebec-488f-b5af-c664dd3118b0�Solved: https://playground.solidjs.com/anonymous/c08fc7c2-6006-474e-ba98-d59e766463bf

22 of 27

3. Showing the Future

23 of 27

Mutation

24 of 27

Time Slicing?

I have one last topic I want to talk about related to Suspense and Transitions. So far we have been concerned with what I’d consider navigation or I/O concerns. Things that impact how you manage resources when moving around the application. Honestly this is what excites me the most about these features. As they make async as trustworthy as the synchronous guarantees we’ve always gotten from our frameworks. But I want to take a moment to talk about one other related topic. Time Slicing. React no longer calls this it that. But in Solid this is an independent feature so I needed a name.

The idea is not only looking at promises, but using Transitions to manage any sort of long running task that is considered lower priority. Keep in mind it would have to be pure work and not side effects, as once you apply side effects you need to apply them all to be consistent. So this won’t help with expensive DOM operations or things related to rendering but with systems with hundreds/thousands of slow distributed computations to become non-blocking.

25 of 27

Scheduled Queuing

Event

Pure Computation

Render Effects

User Effects

setState(value)

VDOM = fn(state)

Diff and Patch

useEffect(fn)

setSignal(value)

createMemo(fn)

createRenderEffect(fn)

createEffect(fn)

26 of 27

Async Consistency

27 of 27

www.solidjs.com

@RyanCarniato

youtube.com/@ryansolid