You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 11, 2024. It is now read-only.
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.
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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: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?
The text was updated successfully, but these errors were encountered: