Skip to content
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

[Buttons] Implement a color themer for an MDCFlatButton #3308

Merged
merged 36 commits into from
Apr 11, 2018

Conversation

yarneo
Copy link
Contributor

@yarneo yarneo commented Apr 10, 2018

Addition of a unit test, and updated example to use the new themer.

Pivotal: https://www.pivotaltracker.com/story/show/156640819

simulator screen shot - iphone 8 - 2018-04-10 at 16 03 30

@yarneo yarneo requested a review from a team April 10, 2018 13:08
@@ -30,6 +30,14 @@
+ (void)applySemanticColorScheme:(nonnull id<MDCColorScheming>)colorScheme
toButton:(nonnull MDCButton *)button;

/**
Applies a color scheme to theme to a MDCFlatButton.
Copy link
Contributor

Choose a reason for hiding this comment

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

Super-nit: Should be "an MDCFlatButton". Please don't fix unless you have other changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated and also other "a" -> "an" in the rest of the header for consistency.

/**
Applies a color scheme to theme to a MDCFlatButton.

@param colorScheme The color scheme to apply to MDCFlatButton.
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Should be, "... to apply to @c flatButton." (referencing the other parameter).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated, and rest of header to comply with this.

Applies a color scheme to theme to a MDCFlatButton.

@param colorScheme The color scheme to apply to MDCFlatButton.
*/
Copy link
Contributor

Choose a reason for hiding this comment

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

LINT: Missing param for flatButton

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, updated

[flatButton setBackgroundColor:[colorScheme.primaryColor colorWithAlphaComponent:0.f]
forState:UIControlStateHighlighted];
[flatButton setBackgroundColor:[colorScheme.primaryColor colorWithAlphaComponent:0.f]
forState:UIControlStateSelected];
Copy link
Contributor

Choose a reason for hiding this comment

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

Just curious, but why use "primaryColor" with alpha 0 instead of UIColor.clearColor or nil? Also, can you not depend on the "fallback" behavior for the background color and only set the UIControlStateNormal value? I'm curious about the result if another class sets a combination of the states (since they are an NSOption), like UIControlStateSelected | UIControlStateHighlighted.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 that these should likely just be clear.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, can you not depend on the "fallback" behavior for the background color and only set the UIControlStateNormal value?

There's some nuance here. I think the expectation of our themers is that they enforce a particular theme on a component. If someone else had modified any of these states prior to us applying the theme then presumably we'd want to blow away those modifications. This unfortunately may mean we have to iterate over every state combination...but I'm really unhappy about that as a solution as well. What do y'all think?

Copy link
Contributor

Choose a reason for hiding this comment

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

I prefer to rely on fallback behavior - I think most clients will expect that. UIKit tends to document that same expectation. It's often worded like, "at a minimum set the title for the .normal state." If we are going to pick out specific states (like .disabled), there should be a difference between that state and .normal.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had the same approach in terms of the background color, but I wanted to follow the params doc guidelines and there they stated primaryColor + opacity of 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, the reason I set all the states is because if a client changed the color of a state prior to the theming, the theming wont override that color to its rightful theming.

Copy link
Contributor

Choose a reason for hiding this comment

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

The params doc unfortunately doesn't have any awareness of a "clear" color, so they specify colors in terms of color + opacity. This isn't a color that is intended to be mapped by the color system because the opacity is always going to be 0, so for our purposes I believe it's sufficient to use clearColor.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sgtm, will update accordingly

Copy link
Contributor

@romoore romoore Apr 10, 2018

Choose a reason for hiding this comment

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

So should all of the states be added to the map instead of nilling-out and relying on the fallback? I'm curious because this affects how I write a lot of component/themer code in general.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

after speaking to both, have moved to a fallback to .normal approach with .normal and .disabled set in the themer.

XCTAssert(
CGColorEqualToColor([button backgroundColorForState:UIControlStateDisabled].CGColor,
[colorScheme.primaryColor colorWithAlphaComponent:0.f].CGColor));
XCTAssertEqual(button.disabledAlpha, 1.f);
Copy link
Contributor

Choose a reason for hiding this comment

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

Please use XCTAssertEqualWithAccuracy for floating point comparison.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@@ -43,6 +43,8 @@ - (MDCButton *)buildCustomStrokedButton {
- (void)viewDidLoad {
[super viewDidLoad];

id<MDCColorScheming> colorScheme = [[MDCSemanticColorScheme alloc] init];
Copy link
Contributor

Choose a reason for hiding this comment

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

I typically expect protocols in the context of interfaces, methods and delegate.
It seems strange to have it as the sole reference to a concrete object.
Consider changing to:
MDCSemanticColorScheme *colorScheme = [[MDCSemanticColorScheme alloc] init];

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

[flatButton setTitleColor:colorScheme.primaryColor forState:UIControlStateNormal];
[flatButton setTitleColor:[colorScheme.onSurfaceColor colorWithAlphaComponent:0.26f]
forState:UIControlStateDisabled];
flatButton.disabledAlpha = 1.f;
Copy link
Contributor

Choose a reason for hiding this comment

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

@romoore @yarneo Should we be resetting all of the states to nil before setting our own colors here?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would suggest two parts:

  1. Set only those states set by the target class. Nilling-out anything that should fall-back to .normal
  2. Write unit tests to verify the behavior of all possible states.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated :) PTAL

@yarneo yarneo merged commit 482bd56 into material-components:develop Apr 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants