Rename Suspense?

[Skn0tt]

As brought to my attention by @flybayer: Should the Suspense component be renamed?

(Source)

What do you all think about this? What are the pros/cons of calling it Suspense, compared to something like LoadingBoundary?

[debs-obrien]

Other frameworks such as Vue are also using calling it <Suspense> but probably of course inspired by React but perhaps something to take into consideration. I do like <LoadingBoundary> though as <Suspense> is quite hard to explain. I kinda try think of it as something suspending ie hanging from somewhere until it is ready to come down to the page. Just my way of getting my head round it. <LoadingBoundary> is much clearer for sure and makes it simpler to understand. But for sure there could be other reasons why its called <Suspense>

[drcmda]

I prefer "suspense", which has been a stable part of React since version 16. Renaming it would cause so much confusion. Naming it anything "loading" would even do it a disservice because a component can suspend for anything: waiting for a worker to proceed, crunching numbers, control flow where a sub tree suspends because i want it to (<Delay /> letting the browser breathe before running animations, etc).

From how i use it i couldn't come up with a better name, it describes perfectly what it's for: suspending execution until resumed. "Loading" is very specific, suspense isn't concerned with the "why" and imo shouldn't bear the name of a single use case out of many.

[debs-obrien]

Great explanation @drcmda

[lintonye]

The name "Suspense" has been growing in me.

The major reason I initially found it a scary word was that it literally talked about too much implementation details: "the temporary cessation or suspension of something." It's perhaps accurate but it sounds scary unless you understand how concurrent rendering works. I thought it would be mental block for beginners.

I started to change my mind once I realized that the word has another meaning: "a state or feeling of excited or anxious uncertainty about what may happen.", as in "Don't keep me in suspense."

So if to most people "suspense" is a common word which means the second one, I'm in support.

[gaearon]

There's also the word "suspend" (verb) which is more or less same as "pause". "Stop, but not completely."

So if something is suspended... it's sort of in suspense. :-)

[chantastic]

"Suspense" is whimsical. I like it for that. Whimsical names have a way of being very adaptable over time.

Two observations I have with the tweet suggested:

• "LoadingBoundary" narrows the logical scope of Suspense to fetching — which is a very narrow Suspense's use-case. Adopting "loading" language would feel very odd in the "Debounce" use-case, for example
• ErrorBoundary — while a placeholder name in documentation — is a user-defined component. API symmetry isn't guaranteed. That said, I do see how appending "Boundary" is interesting for other reasons. Doing so "nounify"s the component name to match spoken language. "Suspense boundary" was used fairly consistently in the 2019 announcement and demonstration language. And is helpful in understand its role/utility in a component tree.

[gaearon]

There's an interesting (probably to no one but us...:D) bit of history there.

There are two separate features:

1. Showing a placeholder while something is loading
2. Showing previous data while next data is being refetched

In the original API, the first use case was handled by a <Placeholder> component. While "Suspense" referred to the second feature. It's because it was as if the screen "suspended" or "in suspense" (in anticipation) of navigation -- but we're not yet showing the result because we're waiting on something.

When we were releasing 16.6 in 2018, we needed to settle on the name for the first concept. "Suspense" as a brand name already had recognition from the demo so we just went with that. The thinking was that the second feature ("staying on older screen") will be a part of it.

But then we ended up changing how the second feature works. It turns out it's not a good default! People don't want to wait for a full screen to be ready to navigate. Actually, you want to show something new as soon as you have something to show. (But you don't want to hide something you're already showing.) That's how the new algorithm works. But the way you opt into "showing existing content while refetching" is by startTransition now!

So the concept that originally was called "suspense" ended up being managed via startTransition, and the concept that was originally called "placeholder" ended up being called "suspense". Because we thought they'd be the same thing, but they ended up being different.

And this is where we are today. :-)

[sophiebits]

If I recall correctly, we also didn't love the name Placeholder, since it was a bit confusing that you'd wrap the non-placeholder children of your app in it! Which pushed us to Suspense as an alternative with less preexisting semantics (and we did also like how it's a bit whimsical, to @chantastic's point).

If anything, the fallback prop could've been named placeholder, but I'm not sure that either name is significantly clearer than the other.

[chantastic]

love this little nugget of history. funny seeing how things get tangled and twisted around with time 😁

[chantastic]

@sophiebits yes! agreed on both points. Placeholder ergonomics would be peculiar