Skip to content
This repository has been archived by the owner on Jan 11, 2024. It is now read-only.

Common components refactor empty state #502

Open
christiemolloy opened this issue May 14, 2021 · 1 comment
Open

Common components refactor empty state #502

christiemolloy opened this issue May 14, 2021 · 1 comment

Comments

@christiemolloy
Copy link
Contributor

As I was writing up some documentation, I realized that under common components we have a couple of very similar components that I think can be grouped together:

  • Empty State
  • Error Boundary
  • Full Page Error
  • Page Not Found

IMO we could have one component for empty state and one for full page errors. OR one for all empty states/error states.

@jgiardino thoughts?

@jgiardino
Copy link
Contributor

Ha ha, I was just noting this in the application-serivces-ui readme PR. I was confused and thought it was a mistake that these were listed as separate items.

This is a hard one. I feel like I don't know enough about:

  • how page layouts are achieved (and if we provide components that render an entire page, is there a chance for inconsistency with how other pages are structured in an application—e.g. if we have a full page that displays a title, that title could look different than how titles display in the rest of the app)
  • what error boundary provides
  • what full page error provides

So my suggestions could be wrong. But...

One approach we could take is to provide each empty state use case with just the empty state component. And the empty state component handles all the things related to contents, icons, sizes and spacing based on either use case or context.

And then maybe there's a separate page component that supports very specific use cases like page not found, full page error, loading, and this component can consume the empty state component and automatically render the appropriate empty state variant based on the desired full page variant.

Or another approach is for any empty state where we know exactly what the full page would look like, we don't provide that as an EmptyState variant, and it's only a FullPage variant.

It's probably worth taking the time to identify in a spreadsheet all the use cases and their desired effect on the UI to then see how it makes sense to group these in common components. If that's helpful, then feel free to assign this issue to me, and I'll capture this info.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants