Hacker News Reader

Comment by ljoshua | Hacker News Reader

So I'm not entirely clear on the advantage that Suspense has over the typical pattern of loading data in componentDidMount, and just having a bit of logic that checks whether your data has loaded or not and renders the spinner or the actual contents. It's not really a hard pattern to implement, though sure, it takes a few extra lines. Seems like the <Suspense> component just kind of abstracts this a bit? What am I missing?

View on HN

I had the same question as you, but I think that the advantages are that (1) the parent is in control of the spinner, but (2) the child is in control of the data.

In most apps I've worked with, either (1) or (2) doesn't hold.

(1) The child is in control of the spinner:

    <Parent>
        <Child />
    </Parent>

    Child() {
        if (!data) {
            return <Spinner />
        }
        return <Data />
    }

(2) The parent is in control of the data

    <Parent>
        { state.data
          ? <Child data={data} />
          : <Spinner />
        }
    </Parent>

With Suspense, the child fetches its own data, but the parent is in control of the spinner:

    <Parent>
        <Suspense fallback={<Spinner />}>
            <Child />
        </Suspense>
    </Parent>

So the Child doesn't need to know the details of how the parent app wants to deal delays.

Suspense then seems to make it easier to parallelize the data requests, and have a spinner at the lowest parent with a child waiting for data.

Also on this topic, the beta React lets you treat loading of both child components and or child data dependencies at a chosen level, bringing them in line with Error Boundaries.

I think going all on on components is very easy to reason about. Same direction React Router went with component based routing making it very easy to for example have:

- logged in user portal - catch all errors and show a fallback UI - lazy load child components by routes with fallback loader UI - use a loader fallback potentially for data dependency too.

I mean, it's not perfect and I can see issues people are mentioning, but it feels pretty good to develop with.

Add to this styled components and everything is so component based it's really nice. One main paradigm for the whole front-end.

I don't think it's the best thing ever, but I've enjoyed the newer approaches when working with them.

A lot of the React Suspense talks explore the concept of "rhythm" and Suspense was built to give the developer greater control of the dance and flow of loading states between components. From simply things that you could presumably bubble up into parent component state like "wait until everything loads, not just some of it" to much more complex dances like "don't show a loading screen at all if this part of the data arrives in the next 200ms, otherwise wait for this other part, show these three components in this specific order, then everything else as it comes in", with all sorts of things in the middle including basic buffering of things to particular timings of animation requested steps to lower "jitter" frequency of your UI as the Framework helps loading data clump into batches instead of individual component each individually signaling state changes for rerenders.

You have control on where to put `Spinner` component instead of putting it in all child component that needs "spinning"

It is as pedestrian as you describe. It is an opinionated loading framework that binds timing and component responsibility...just like backbonejs or any other popular solution...except this is tied to the heavy react ecosystem. It doesnt change the way anyone thinks about data.

Reply on news.ycombinator.com