This repository was archived by the owner on Mar 4, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 53
fix(Button): icon colors and layout #135
Merged
Merged
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
7689f77
fix layuot and icon color of Button
kuzhelov-ms f81b239
fix color stylings of Button
kuzhelov-ms aeded91
fix children API
kuzhelov-ms 05fe3fc
align content to center
kuzhelov-ms 66dab28
remove unused 'content' prop from styles
kuzhelov-ms cc35644
fix color applied for hover state
kuzhelov-ms 7627b6c
fix child API
kuzhelov-ms a048e8e
use site variable to initialize default color
kuzhelov-ms a4f5d32
Merge branch 'master' into fix/button-layout-and-icon-color
kuzhelov-ms 94a0606
changelog
kuzhelov-ms c1d5714
Merge branch 'master' into fix/button-layout-and-icon-color
levithomason File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Any variables or styles used directly in a component's logic implicitly become part of a global theming interface.
All themes will have to implement
variables.typePrimaryColor
, for instance, in order for this to work. Additionally, we are removing the styling from the theme and baking it into the component instead.I think all theming values and theming logic should live in the theme's files. This way, each theme is free to choose the values and logic behind their styles. The question is how?
Proposal 1 - Component part variables
Component variables files could define variables for each component parts as well. Then, variable values and logic for component parts can be left to the theme and not dictated to all themes by the component. Here's an example of the Button theme defining an
icon
part in its variables.Now, the component simply implements a contract that says "we pass variables[part] to each component part":
This would also allow us to do this consistently for all components, including the styles for each component part. That then would allow us to write a conformance test for it. This would make the API easier to understand and work with as well since there is only one concept, "components pass variables/styles to each component part".
Proposal 2 - A high-level theme interface
This proposal would introduce a new concept. Something like a lightweight theme interface that is allowed to pass between components. It would consist of
backgroundColor
,foregroundColor
, and perhaps anaccentColor
initially (names and keys are inspired by present convergence talks with several teams at Microsoft).The Button in this case would define these three values for its bounds. Then, they would passed to the Icon.
There are a lot more considerations here, but I'm less in favor of this pattern for the problem at hand so I'll leave it here for now.
Thoughts?
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.
yes, agree with the reasons provided above, thanks - this goes in line with the exactly the same discussion we've had with Miro. For the sake of avoiding to introduce additional complexity at that moment we've decided to move forward with the simplest approach that would indicate our intent to pass variables to child component, and after that introduce changes in a way that theming aspects will be completely separated from logic.
Speaking of the options suggested - I would definitely support the first one, as it suggest clear path that not changes but extends approach we are using now - and, thus, it is not associated with significant complexity increase. Also, with this one we will be able to address quite broad set of scenarios we are currently struggling with (or using the approach where variables are coupled with implementation)
Not saying 'no' to the second option, though - but would rather wait once this concept will solidify in our minds, for the sake of us being absolutely sure about what we are buying for additional efforts laid in this direction, as well as whether this concept is able to cover the cases we are interested in (and how flexible it would be to cover potentially emerged edge-cases)
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.
for the sake of progressing with that, let me suggest the following steps:
This will allow us to progress with fixes, as well as split these subsequent changes so that it would be easier to review them.
Please, let me know what do you think about it. Thanks!
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.
agreed, let's merge this