Skip to content

refactor: use the new button component on forms and dialogs #16050

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 20 commits into from
Jan 7, 2025

Conversation

BrunoQuaresma
Copy link
Collaborator

This is a significant PR that will impact many parts of the UI, so I’d like to ask you, @jaaydenh, for a very thorough review of the Storybook stories on Chromatic. I know it’s a bit of a hassle with around 180 stories affected, but it’s all for a good cause 💪

Main changes:

  • Update the Button component to match the new buttons design.
  • Update forms and dialogs to use the new Button component.

Related to #14978

@BrunoQuaresma BrunoQuaresma self-assigned this Jan 6, 2025
@@ -43,10 +43,12 @@ module.exports = {
secondary: "hsl(var(--surface-invert-secondary))",
},
error: "hsl(var(--surface-error))",
destructive: "hsl(var(--surface-destructive))",
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe that surface-destructive and border-destructive is meant to replace surface-error and border-error

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good catch! 👍

@jaaydenh
Copy link
Contributor

jaaydenh commented Jan 6, 2025

@BrunoQuaresma there are still a few places that still use the existing MUI button. for example in FullPageHorizontalForm.tsx. If there is a specific reason to wait on these, it may be useful to create a separate issue to handle those buttons.

{jobError ? "Retry" : "Create template"}
</Button>
{logs && (
<button
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a specific reason not to use the new button component here?

<FormFooter>
<Button type="submit" disabled={form.isSubmitting}>
{form.isSubmitting && <Spinner />}
Create organization
Copy link
Contributor

Choose a reason for hiding this comment

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

I am changing this button in a separate PR being reviewed now. It may be best to not make this change here to avoid merge conflicts.


<Button type="submit" disabled={isLoading}>
{isLoading && <Spinner />}
Create group
Copy link
Contributor

Choose a reason for hiding this comment

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

In the new designs I have seen from Christin, I have seen buttons of this type being named "Save". I could be useful to confirm if the new naming pattern for form buttons is "Cancel" and "Save"

Copy link
Contributor

@jaaydenh jaaydenh left a comment

Choose a reason for hiding this comment

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

I went through all the storybook changes and looks good. I think the the main thing to confirm is if the buttons previously named "Submit" should now be named "Save" so that we start to get more consistency in button naming.

@chrifro
Copy link

chrifro commented Jan 7, 2025

I think the the main thing to confirm is if the buttons previously named "Submit" should now be named "Save" so that we start to get more consistency in button naming.

⬆️ Let's do that. "submit" indicates that something needs to be reviewed before it becomes active while "save" indicates immediate confirmation and with that comes peace of mind.

@BrunoQuaresma
Copy link
Collaborator Author

⬆️ Let's do that. "submit" indicates that something needs to be reviewed before it becomes active while "save" indicates immediate confirmation and with that comes peace of mind.

I don’t think we currently have any form actions that require an additional confirmation step, so all the forms would use "Save." That said, I think "Save" is a bit too generic—we could make the action clearer to the user by labeling the button based on the context. For example, if a user is editing a workspace, we might want to label the button as "Save Workspace" instead of just "Save."

That being said, I don’t have a strong opinion or any supporting studies/articles about this approach, so I’m fine with sticking to "Save" or "Submit" if that’s preferred. I just wanted to bring this up for discussion!

cc.: @chrifro @jaaydenh

@chrifro
Copy link

chrifro commented Jan 7, 2025

Let's stick to "Save" as the default. The context should already be very clear in most cases. Using specific naming might not work for all cases or the button could get very wide which might break the page layout.

Quick benchmark:
Vercel, Figma, -> "Save"
Google, Slack -> "Save changes"
GitHub -> "Save plus specific context"
Linear, Apple -> no save button, saves automatically

@BrunoQuaresma
Copy link
Collaborator Author

@jaaydenh I’ll keep #14978 open until I’ve removed all the MUI Buttons from our codebase, so there’s no need to create a new issue. Wish me luck! 🤞

@BrunoQuaresma BrunoQuaresma merged commit cb6facb into main Jan 7, 2025
29 checks passed
@BrunoQuaresma BrunoQuaresma deleted the bq/refactor-buttons-1 branch January 7, 2025 17:29
@github-actions github-actions bot locked and limited conversation to collaborators Jan 7, 2025
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.

3 participants