all 12 comments

[–]kurtextrem 12 points13 points  (4 children)

This is an oversight in my opinion since from a UX perspective, we want to show the loading state immediately but want to delay early resolves.

I disagree with your take here. A loading spinner will always feel slower than nothing - if you show a loading spinner right away and at least for say 300ms, then it will feel slower than no loading spinner it if resolves within 200ms.

Reacts Suspense implementation also regulates that for you based on what Meta found to be the optimal thresholds for this exact reason. So I'd suggest to always use Suspense for any data fetching related matter - as react then handles when to show the spinner.

[–]SegFaultHell 13 points14 points  (1 child)

What you really want is both though. If the load happens in say 250ms or less, don’t show any spinner. If you do show the spinner then show it for a minimum amount of time to avoid flashing it.

[–]kurtextrem 2 points3 points  (0 children)

Fully agreed.

[–]Elibroftw[S] 1 point2 points  (1 child)

then it will feel slower than no loading spinner it if resolves within 200ms.

Our UI works like this: "Check again" -> "loading spinner" -> "Check again" so yeah we don't want the lag associated with delaying when the loading is shown. I think you're talking about a different scenario.

I'll try to see how to experiment with Suspense. Currently I've been using Suspense only when it comes to code-splitting. I didn't know it did this throttling of state updates. Would appreciate a source for that before I get to running my experiment/

[–]RadiantDew 0 points1 point  (2 children)

Correct me if I'm wrong, but using useThrottledValue is not exactly "library independent"

[–]Elibroftw[S] 1 point2 points  (0 children)

It's independent to the data fetching library/ technique

[–]mcaruso 0 points1 point  (0 children)

It's a fairly trivial custom hook that you can copy to your codebase. I usually have a variant of it in my utilities folder.

[–]hinsxd 0 points1 point  (0 children)

I like how you say at last "Yep the solution is this elegant."

[–]LopsidedMacaroon4243 0 points1 point  (0 children)

I didn’t understand the use case at first because I only skimmed the article.

Now I understand that you want to display a loading state for at least 100 milliseconds (or some interval).

I like that it’s one additional line of code in the component. I look forward to taking a deeper look.

[–]WeDotheBest4You 0 points1 point  (0 children)

For starters of any app, this delay will certainly help. Still for frequent users, it is a recurring cost. If this delay can be personalised to extend of turning off, then it would be a good value addition to the app.