Skeleton Loading States

[vankhoawin]

The Spinner component is useful for showing that sections of a page are loading, but there are some reasons why skeleton loading states could possibly provide better UX than Spinners (I won't list them, there's enough articles on Google for that). But the main point I would say is to "bring placeholders closer to their content."

Examples:

Medium

Google Drive

[aayushpi]

Thank you @vnguyen94! Personally, I'm in favor of this feature. Let's keep this discussion open and solicit demand for it so we can consider how we may prioritize it. It may also be a good contribution. I believe @GiantRobots has some examples he'd like to add too

[GiantRobots]

[GiantRobots]

Those mostly show some skeleton ui's with cards/tables. We have 3 loaders for SG the fragment loader, the SG loader, and the table loader each with differing rules on how to implement them located in the styleguide

http://styleguide.sendgrid.com/loaders.html
http://styleguide.sendgrid.com/tables.html#tables-loading

I think it helps a lot in the feeling that you navigated instead of throwing a large "page" loader instead of the skeleton pages. It can also help with reflow issues.

Some of the issues we've experienced around them however include scopes/flags/user perms on a feature that show the skeleton outline and then we use a card to indicate they don't have access to the feature. That experience can be jarring at times but we normally have to deal with it because of race conditions for when http requests normally resolve.

[GiantRobots]

There's some interesting conversation about how applications load their data in the react docs

https://reactjs.org/docs/concurrent-mode-suspense.html#traditional-approaches-vs-suspense

I think we use the fetch-on-render paradigm which leads to lots of waterfall http requests as well as waterfall layouts.

More fun thoughts from the suspense doc.

Note how we eliminated the if (...) “is loading” checks from our components. This doesn’t only remove boilerplate code, but it also simplifies making quick design changes. For example, if we wanted profile details and posts to always “pop in” together, we could delete the boundary between them. Or we could make them independent from each other by giving each its own boundary. Suspense lets us change the granularity of our loading states and orchestrate their sequencing without invasive changes to our code.

Using the suspense api will eventually allow us to pull the loading parts of our components out and decide where the barriers are. We may want to provide insight on how to handle the various application loads users of the library will encounter to keep our UI eventually consistent

[SiTaggart]

@GiantRobots @vnguyen94 Referencing prior art, would something like Chakra UIs skeleton component fit the use cases you are thinking?

https://chakra-ui.com/skeleton

[vankhoawin]

For our team's use cases, I think so yes; our team doesn't have any out-of-the-ordinary flows (Studio/Flex come to mind). We'd use skeletons as placeholders for loading lists and sections, so having a base Skeleton component would let us compose those larger molecule components.

[GiantRobots]

I like the API for that but we should keep an eye on the suspense API and how to build skeletons for that.

If we use the same API from Chakra for our own Skeletons

import { Box } from "@chakra-ui/core";

function Card() {
  const { data, loading, error } = useRemoteData();
  if (error) return <Box children="error" />;
  return (
    <Box>
      <Skeleton isLoaded={!loading}>
        <Heading>{data.title}</Heading>
      </Skeleton>
    </Box>
  );
}

And use it for Skeletons/Loaders with suspense

function Card() {
  return (
    <Box>
      <Suspense fallback={<Skeleton>Fake Child Components so it renders correctly</Skeleton>}>
        <ComponentThatDoesFetching>My Awesome component</ComponentThatDoesFetching>
      </Suspense>
    </Box>
  );
}

We get some weirdness with layout. It might be better to have Card/Box Skelly, Table Skelly, etc. for the various use cases.

There was some weirdness with the implementation for SendGrid tables where it required the tables to be empty to get the loading to trigger because it was implemented in css 100%. So sometimes we'd get weird bugs where prettier added a space and a row component would stop loading (I would prefer an explicit API for those states) or specific components for them.

So I guess my recommendation is some combination of Skeleton with isLoaded for current ease of use, and maybe in the future a suspense wrapper.

After thought, we can also implement the Skeleton loader like this

const SuspenseSkelly = ({children}) => {
<Suspense fallback={<Skeleton>{default size}</Skeleton>}>
       {children}
</Suspense>
}

// Using it would look like

<SuspenseSkelly>
      <MyComponentWithSuspense />
</SuspenseSkelly>