This is how it's used in user-settings-modal The thought is to add a new variant for each button. But, maybe having an approach where the button takes in color, background, size and shape props would be more flexible.

<Button
          variant="danger"
          type="submit"
          onClick={this.onDelete}
          disabled={inputDisabled}
        >
          Delete account
        </Button>

• we can update the button to have no-wrap
• my thought was to introduce a new variant to support this button, like transparent.
• to your point: https://github.com/CommE2E/comm/blob/master/web/components/button.css#L5, I don't think I should have given this button a default color, and then overwritten the value with another class.

Having a really reusable button might make sense, but I'm not sure if this is the best idea. Even if we have some reasonable defaults, it will be harder to use than a limited set of predefined variants (especially when dealing with different themes).
Ultimately, the design should define a couple of variants and no other variant should appear in the app. In that case, introducing a text variant should be the best idea here, but I'll need to check the designs if that's possible.
As a side note: a configurable button (or any component) should be able to receive e.g. color props, which isn't that comfortable without any CSSinJS solution.

I think it doesn't make sense to block this diff on this comment. I created a linear issue https://linear.app/comm/issue/ENG-843/introduce-text-button-type where a new button type will be introduced and used here. @benschac

We should pretty much never call a server call "nakedly" like this. It should be wrapped in a dispactionActionPromise. This resulted in ENG-1604