Skip to content

feat(site): move history into sidebar #11413

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 11 commits into from
Jan 5, 2024
Merged

Conversation

BrunoQuaresma
Copy link
Collaborator

Screen.Recording.2024-01-04.at.13.50.39.mov

@BrunoQuaresma BrunoQuaresma requested a review from a team January 4, 2024 18:47
@BrunoQuaresma BrunoQuaresma self-assigned this Jan 4, 2024
@BrunoQuaresma BrunoQuaresma requested review from code-asher and removed request for a team January 4, 2024 18:47
@Parkreiner
Copy link
Member

Ran out of time to start on this today, but I'll be starting on this first thing tomorrow morning!

Copy link
Member

@Parkreiner Parkreiner left a comment

Choose a reason for hiding this comment

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

Looks really good! Just had a few niggling comments

return <Link css={styles.sidebarItem} {...props} />;
};

export const SidebarItem = (props: HTMLAttributes<HTMLButtonElement>) => {
Copy link
Member

@Parkreiner Parkreiner Jan 5, 2024

Choose a reason for hiding this comment

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

Just for future-proofing, do you think it's worth explicitly pulling the type attribute out and setting its default value to button?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not sure if I got it... do you have a code sample?

Copy link
Member

@Parkreiner Parkreiner Jan 5, 2024

Choose a reason for hiding this comment

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

Sorry, just realized that the comment got garbled by a stray backtick

Now that I'm a little more awake, I think my suggestion would be overkill, but I was talking about this:

export const SidebarItem = ({
  type = "button",
  ...delegatedProps
}: HTMLAttributes<HTMLButtonElement>) => {
  return <button css={styles.sidebarItem} type={type} {...props} />;
};

<div css={{ padding: 16 }}>
<LoadingButton
fullWidth
onClick={() => buildsQuery.fetchNextPage()}
Copy link
Member

Choose a reason for hiding this comment

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

Could this be simplified to onClick={buildsQuery.fetchNextPage}?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No, because the onClick event pass an Event object and the fetchNextPage receives a different argument type

// Watch workspace changes
const updateWorkspaceData = useEffectEvent(
async (newWorkspaceData: Workspace) => {
if (!workspace) {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe it's just because it's still early for me, but I got confused for a second when reading this code because I didn't realize thought the check was for the old workspace, and not the new one

Do you think it's worth renaming workspace to currentWorkspace, to make the difference between new and old a little more clear?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This workspace is a prop from the WorkspacePage so I don't think renaming it would make it look good at the component level. Eg. <WorkspacePage currentWorkspace={workspace} /> does not make too much sense to me.


{buildLogs}

{typeof resources !== "undefined" && resources.length > 0 && (
Copy link
Member

Choose a reason for hiding this comment

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

Could the condition be simplified to resources?.length > 0?

Copy link
Collaborator Author

@BrunoQuaresma BrunoQuaresma Jan 5, 2024

Choose a reason for hiding this comment

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

No, because typescript will throw an error:

Screenshot 2024-01-05 at 11 59 55

But it can be something like resources && resources.length > 0

Copy link
Member

Choose a reason for hiding this comment

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

Oh, that's my mistake – this is one of those things that's technically safe in JavaScript (undefined > 0 evaluates to false), but TS wouldn't be happy

@BrunoQuaresma BrunoQuaresma merged commit c428395 into main Jan 5, 2024
@BrunoQuaresma BrunoQuaresma deleted the bq/update-history-on-ws-page branch January 5, 2024 16:32
@github-actions github-actions bot locked and limited conversation to collaborators Jan 5, 2024
@BrunoQuaresma
Copy link
Collaborator Author

Related to #11491

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

Successfully merging this pull request may close these issues.

2 participants