-
Notifications
You must be signed in to change notification settings - Fork 21
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
<EnvBuildStatus /> component #377
Conversation
Marking this as draft until I update Storybook |
There was a problem hiding this 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.
}); | ||
|
||
it("should display builds in the dropdown", async () => { | ||
// This is what the dropdown should display for the build | ||
const dropdownOptionName = buildDatetimeStatus( |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, thanks!
There was a problem hiding this 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 🚢
); | ||
}; | ||
|
||
export interface IEnvBuildStatusProps { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
export interface IEnvBuildStatusProps { | |
interface IEnvBuildStatusProps { |
} | ||
|
||
export const EnvBuildStatus = ({ build }: IEnvBuildStatusProps) => { | ||
const logArtifact: Artifact | never = artifactList(build.id, ["LOGS"])[0]; |
There was a problem hiding this comment.
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. 🤔
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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.
src/utils/helpers/buildMapper.ts
Outdated
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); | ||
} |
There was a problem hiding this comment.
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.
src/utils/helpers/buildMapper.ts
Outdated
const BUILD_STATUS = ["QUEUED"]; | ||
return BUILD_STATUS.includes(status); | ||
}; | ||
const isCompleted = ({ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 = ({ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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.
export interface IEnvBuildStatusProps { | |
interface IEnvBuildStatusProps { |
src/utils/helpers/buildMapper.ts
Outdated
const BUILD_STATUS = ["QUEUED"]; | ||
return BUILD_STATUS.includes(status); | ||
}; | ||
const isCompleted = ({ |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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 = ({ |
There was a problem hiding this comment.
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]; |
There was a problem hiding this comment.
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.
Tests pass, runs locally, looks good in Storybook. Merging in now. |
Follow up, clean up to #367.
Description
This pull request:
Pull request checklist
Additional information