Skip to content
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

<EnvBuildStatus /> component #377

Merged
merged 9 commits into from
Mar 26, 2024

Conversation

gabalafou
Copy link
Contributor

@gabalafou gabalafou commented Mar 5, 2024

Follow up, clean up to #367.

Description

This pull request:

  • Refactors out some of the code in the EnvBuild component into EnvBuildStatus
  • Renames the export of BuildDropdown.tsx to match the file name
  • Some code clean up for clarity

Pull request checklist

  • Did you test this change locally?
  • Did you update the documentation (if required)?
  • Did you add/update relevant tests for this change (if required)?

Additional information

@gabalafou gabalafou marked this pull request as draft March 5, 2024 22:43
@gabalafou
Copy link
Contributor Author

Marking this as draft until I update Storybook

@gabalafou gabalafou marked this pull request as ready for review March 14, 2024 21:45
Copy link
Contributor Author

@gabalafou gabalafou left a comment

Choose a reason for hiding this comment

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

Done self-reviewing. I decided it didn't make sense to create a separate Storybook story for the EnvBuildStatus component. I think the EnvBuilds story is sufficient.

src/utils/helpers/buildMapper.ts Show resolved Hide resolved
test/helpers/BuildMapper.test.tsx Show resolved Hide resolved
});

it("should display builds in the dropdown", async () => {
// This is what the dropdown should display for the build
const dropdownOptionName = buildDatetimeStatus(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Feels a little funky to me to call a function here rather than to just hard-code the string, perhaps I should go back and update this

Copy link
Contributor

Choose a reason for hiding this comment

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

Well, if your hesitation is that BuildDropdown uses buildDatetimeStatus to create the string, remember that you're already testing buildDatetimeStatus elsewhere. So I think this is fine, this test is really checking that the correct text appears in the element, not that buildDatetimeStatus makes the right string. Anyway, if you'd prefer this test looks different I'll defer to you, but IMO this is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, thanks!

Copy link
Contributor

@peytondmurray peytondmurray left a comment

Choose a reason for hiding this comment

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

Thanks for this, this cleans things up nicely. The one main comment I had was the question about combining the BUILDING and QUEUED statuses into one label shown to the user, but otherwise this LGTM 🚢

src/utils/helpers/buildMapper.ts Show resolved Hide resolved
);
};

export interface IEnvBuildStatusProps {
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the usual protocol around exporting these one-off interfaces? I know some projects do so and others don't.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh this isn't needed. It was needed by Storybook when I was importing this component into Storybook, but then I decided not to create a story for this component.

Suggested change
export interface IEnvBuildStatusProps {
interface IEnvBuildStatusProps {

}

export const EnvBuildStatus = ({ build }: IEnvBuildStatusProps) => {
const logArtifact: Artifact | never = artifactList(build.id, ["LOGS"])[0];
Copy link
Contributor

Choose a reason for hiding this comment

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

I checked it out and this seems good, but I can't get over how weird this looks because indexing outside an array's length returns an undefined:

const foo = [1, 2, 3]
foo[8] // Returns undefined

But from what I can tell typescript infers the type for [] to be never[] which is just strange. 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No you're right. My type annotation was wrong. Fixed.

});

it("should display builds in the dropdown", async () => {
// This is what the dropdown should display for the build
const dropdownOptionName = buildDatetimeStatus(
Copy link
Contributor

Choose a reason for hiding this comment

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

Well, if your hesitation is that BuildDropdown uses buildDatetimeStatus to create the string, remember that you're already testing buildDatetimeStatus elsewhere. So I think this is fine, this test is really checking that the correct text appears in the element, not that buildDatetimeStatus makes the right string. Anyway, if you'd prefer this test looks different I'll defer to you, but IMO this is fine.

Comment on lines 18 to 24
let duration = 0;
if (ended_on && scheduled_on) {
const startTime = new Date(scheduled_on);
const endTime = new Date(ended_on);
duration = (endTime.valueOf() - startTime.valueOf()) / 60000;
duration = Math.round(duration);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess you really only need to do this if status === "COMPLETED", so this can be moved inside the branch below.

const BUILD_STATUS = ["QUEUED"];
return BUILD_STATUS.includes(status);
};
const isCompleted = ({
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe this is just a matter of preference but based just on this function's name I'd expect this to return a bool.

One other thing: this is only being called in buildStatus below, do we need to break this out into a separate function? You're already checking the value of status there, so this would be a bit shorter if you weren't checking it again here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I'm fine with that, I'll update in a subsequent commit

status: isCompleted(status, duration),
status_info
};
export const buildStatus = ({
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to combine the BUILDING and QUEUED statuses? It feels like it would be useful to have these distinct states represented distinctly in the UI.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Your suggestion makes sense but I'm a little afraid of it breaking something.

I also thought that maybe it had been a product decision to collapse those statuses for the end user. But that's not stated in the PR where it was introduced.

I'll ask about it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Update. I asked @kcpevey on Slack and she said it looks like a mistake, so I've changed it and we'll see if anybody complains or it breaks anything.

Copy link
Contributor Author

@gabalafou gabalafou left a comment

Choose a reason for hiding this comment

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

Thanks for the thorough review @peytondmurray!

);
};

export interface IEnvBuildStatusProps {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh this isn't needed. It was needed by Storybook when I was importing this component into Storybook, but then I decided not to create a story for this component.

Suggested change
export interface IEnvBuildStatusProps {
interface IEnvBuildStatusProps {

const BUILD_STATUS = ["QUEUED"];
return BUILD_STATUS.includes(status);
};
const isCompleted = ({
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I'm fine with that, I'll update in a subsequent commit

});

it("should display builds in the dropdown", async () => {
// This is what the dropdown should display for the build
const dropdownOptionName = buildDatetimeStatus(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, thanks!

status: isCompleted(status, duration),
status_info
};
export const buildStatus = ({
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Your suggestion makes sense but I'm a little afraid of it breaking something.

I also thought that maybe it had been a product decision to collapse those statuses for the end user. But that's not stated in the PR where it was introduced.

I'll ask about it.

}

export const EnvBuildStatus = ({ build }: IEnvBuildStatusProps) => {
const logArtifact: Artifact | never = artifactList(build.id, ["LOGS"])[0];
Copy link
Contributor Author

Choose a reason for hiding this comment

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

No you're right. My type annotation was wrong. Fixed.

@gabalafou
Copy link
Contributor Author

Tests pass, runs locally, looks good in Storybook. Merging in now.

@gabalafou gabalafou merged commit 7e0fa2a into conda-incubator:main Mar 26, 2024
4 checks passed
@gabalafou gabalafou deleted the env-build-status-component branch March 26, 2024 19:52
gabalafou added a commit to gabalafou/conda-store-ui that referenced this pull request Jul 9, 2024
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