-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[SpeedDial] Change actions background color #14640
Conversation
Details of bundle changes.Comparing: 7a49f80...a19c618
|
@hburrows Hi, we are looking for somebody to take the ownership of this component. Would you be interested in doing so? We were considering the option to drop the support of the component in #12830 (comment), but keeping it in the lab and eventualy move it to the core is a viable option if we have somebody from the community than can take care of it. Alternativelty, we can move it to somewhere else. cc @mbrookes. |
Semi related - looking at the spec, it seems the default color scheme for the FAB is a white icon on a black background, with an option for grey on white, which the speed dial actions use by default. Not sure how that would fit into our current Yes, we'd be gad to have someone take primary ownership of the SpeedDial component - review PRs etc... |
@oliviertassinari @mbrookes I'm tentatively open to helping with the component and shepherding it along into core (eventually). My major hesitation is that I'm not committed to using the component yet (vs. a more traditional popup menu). I like the idea of the speed-dial but my concern is that it might be too confusing for some of my product's users vs a more tradition popup menu opened via the Fab - maybe what I want is the Fab transforming into a menu as defined in the spec. But for now, I'm open to reviewing PRs for the component and doing necessary maintenance/evolution. I use this project a lot so it's only fair that I contribute back 😄 |
Great! Thanks @hburrows. Any thoughts on the MDv2 spec FAB / SpeedDial colors? |
@mbrookes Can you please share a link to the Material Design V2 specs that you're looking at so I know I'm looking at the same thing you're looking at. What I'm looking at doesn't reference any version number. |
Sorry, the current spec. We loosely refer to it as v2 after Google gave it an overhaul early last year. https://material.io/design/components/buttons-floating-action-button.html |
@mbrookes Thanks for confirming the link to the spec -- we're looking at the same thing. The spec is rather vague regarding the exact color scheme, but in the Anatomy section states "The FAB is typically displayed in a circular container. An app’s color scheme determines its color fill, which should contrast with the area behind the FAB." Many of the examples use a FAB with a black fill and a white icon, but just as many use a different color aligned with the theme of the example. I feel that the behavior of the |
Okay, sounds good. Would you like to update the SpeedDialAction default color & customizability as part of this PR, or treat it separately? |
@@ -303,6 +304,11 @@ SpeedDial.propTypes = { | |||
* @ignore |
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.
Just noticed that some of the props above refer to the Button component, whereas the Fab component was extracted out of the Button. Do you want to fix those up?
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.
@mbrookes I'll address the SpeedDialAction color as part of this PR -- I think that makes sense. For expediency, I'm good with fixing the props as part of the PR also.
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.
So... changing from ButtonProps to FabProps is a breaking change... but so is changing the default color for the action buttons but won't break code. Any ground rules for how breaking changes impact "Lab" components? I'm now thinking maybe it's best to change the prop name (ButtonProps -> FabProps) in a separate PR
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.
Technically the only difference is how we change the version number. However, we are a bit more liberal with breaking changes in the lab since the API isn't considered stable.
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'm joining, what's the reasoning against?
<SpeedDial FabProps={{ color: 'secondary' }} />
It looks simple to me.
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 reasoning against that... it just didn't occur to me to express it that way. I guess I was kind of thinking the SpeedDial "is a" special type of Fab instead of "has a" Fab (if that makes any sense)... so I expressed it the same way you would with a Fab (as a direct prop). We're already using FabProps
(or will be in a subsequent PR) so I'm on board with removing the direct color
prop and moving it to ButtonProps
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.
Should I just change ButtonProps
to FabProps
as part of this PR instead of a separate PR?
@oliviertassinari @mbrookes Can either of you help me interpret the Argos-CI error. I'm not familiar with it -- but I suspect changing the default SpeedDialAction background color from grey to white might be the issue. |
@oliviertassinari Thanks for removing that redundant code. I got too wrapped around the axle of this trivial change to actually see that. |
for me wrapping background in style attribute of button worked for me |
The SpeedDial component uses the Fab component but provides no way to control or override the color of the embedded Fab component. This PR continues to default the Fab color toprimary
but does so by utilizing ButtonProps in a manner that allows the caller to provide an override (for example, to usedefault
orsecondary
color).This PR also changes the default SpeedDialAction button color from grey to white whic better aligns with the spec (or at least the examples in the spec).