Skip to content

feat: display specific errors if templates page fails #4023

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Sep 13, 2022

Conversation

presleyp
Copy link
Contributor

I didn't have a ticket for this one, but I noticed while working on this page that it was swallowing errors.

@presleyp presleyp requested a review from a team as a code owner September 12, 2022 17:28
@presleyp presleyp requested review from Kira-Pilot and removed request for a team September 12, 2022 17:28
defaultMessage={t("errors.getTemplatesError")}
/>
) : (
<TableContainer>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find this triple, JSX ternary a little confusing and personally think this is a good candidate for early return.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would you do the early return? I'm not seeing a good way of doing it since the margins and page header need to be there in each case. I could put those in a const but at that point I'd rather put the content (error or data) in a const and still use the conditional so you can easily see what's definitely there vs what's conditional.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might move the margins and page header into TemplatesPage.tsx - they seem like page scaffolding to me. Then, one could decompose the TemplatesPageView file:

export const TemplatesPageView = () => {
  if (props.getOrganizationsError) {
    return <ErrorSummary />
  }

  if (props.getTemplatesError) {
    return <ErrorSummary />
  }

  if (empty) {
    return (
      <TableContainer>
        <LoadingTableBody />
      </TableContainer>
    )
  }

  return (
    <TableContainer>
      <TemplateTableBody templates={templates} />
    </TableContainer>
  )
}

I think the benefit here is we are writing state in a declarative way - it is apparent at a glance what states the developer should be aware of. Let me know what you think!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this looks nice and readable, but the scaffolding is in the view for storybook reasons. I'm open to a refactor but I think I'll leave it for future work so I can get the error handling in.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good!

</TableHead>
<TableBody>
{props.loading && <TableLoader />}
{empty && (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about making a parent table component that accepts a child table body component? That child component could be a loading component, or a data-filled component. I was wondering if breaking apart state into components here might make this a little easier to read and reason about.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a good idea, can you make a ticket for it? We could apply it in multiple places.

@@ -6,23 +6,24 @@ import { XServiceContext } from "../../xServices/StateContext"
import { templatesMachine } from "../../xServices/templates/templatesXService"
import { TemplatesPageView } from "./TemplatesPageView"

const TemplatesPage: React.FC = () => {
export const TemplatesPage: React.FC = () => {
Copy link
Member

@Kira-Pilot Kira-Pilot Sep 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to update the import of TemplatesPage in AppRouter.tsx and in TemplatesPage.test.tsx.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gah, thanks!

<div className={styles.templateIconWrapper}>
<img alt="" src={template.icon} />
</div>
) : undefined
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need a ternary here.

Copy link
Member

@Kira-Pilot Kira-Pilot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good after we fix the import issue!

@presleyp presleyp merged commit 83c35bb into main Sep 13, 2022
@presleyp presleyp deleted the presleyp/template-errors branch September 13, 2022 14:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants