-
Notifications
You must be signed in to change notification settings - Fork 55
chore(colors): Improve colors typings per component variables #1340
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1340 +/- ##
==========================================
+ Coverage 72.99% 73.05% +0.05%
==========================================
Files 776 777 +1
Lines 5828 5848 +20
Branches 1706 1706
==========================================
+ Hits 4254 4272 +18
- Misses 1568 1570 +2
Partials 6 6
Continue to review full report at Codecov.
|
packages/react/src/themes/teams/components/Label/labelVariables.ts
Outdated
Show resolved
Hide resolved
packages/react/src/themes/teams/components/Label/labelVariables.ts
Outdated
Show resolved
Hide resolved
background: color, | ||
foreground: 'rgb(232, 232, 232)', | ||
}, | ||
brand: { |
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.
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.
The problem is that now, we are using one ColorNames type, but this should be redefine for teams theme (we don't have all colors that the typings suggest, and we have few more. Will introduce this changes too.
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.
Introduced TeamsColorNames, a bit scared as how these typings with generics are looking now :S I am open for ides for restructuring them. Will try on my own to see how can I improve these.
foreground: 'rgb(232, 232, 232)', | ||
}, | ||
brand: { | ||
background: siteVars.colorScheme.brand.foreground4, |
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.
not sure if this PR is going to address this, but as a client might see another issue with types. Here you might see that types suggest that foreground
prop is guaranteed to be defined for each color
of colorSheme
.
However, given this code, it is clear that value might be omitted - this is the case of brand
color for Label's color scheme, where foreground
is absent.
It would be great if our types will suggest the fact that value of area props (in our example, foreground
) is, in fact, optional
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.
The color scheme defined for the teams theme, already have all these values defined. In the labelVariables, we are just overriding some of those. Basically there is no need to override the brand foreground hover, that's why it is not defined.
import { ColorPalette, PrimitiveColors, ColorSchemeMapping, ColorVariants } from '../types' | ||
import { ColorScheme } from 'src/themes/types' | ||
|
||
export type TeamsContextualColors = { |
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.
Interfaces added for the Team's specific colors
-added transparent colors in the color palette
type LabelColorSchemeMapping = StrictColorSchemeMapping< | ||
StrictColorScheme<LabelColorComponentAreas>, | ||
TeamsColorNames | ||
> |
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 want us to decide if this is the right approach for defining these, and I will extract this to a separate utility and reuse it in other component variables files.
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.
are we expecting this TeamsColorNames
set to change based on the component type? I think, we might start from exporting simpler StrictTeamsColorSchemeMapping<TComponentAreas>
type that would do this scaffolding in the background. This will make type interface being easier to client.
Also, we might want to rename this type to something like TeamsReducedSchemeMapping<TComponentAreas>
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 would expect that those will be different across different component, as the text have much more color values then the menu for example. (The menu supports only default and brand colors and we want to use that as typings in the styles.)
|
||
export interface LabelVariables { | ||
colorScheme: ColorSchemeMapping | ||
colorScheme: LabelColorSchemeMapping |
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.
This may be a problem when we are using here some base theme interface and want to extend this, as this prop should have a different type..
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 to be sure this is not overlooked - could you, please, suggest an example of this (like, some pseudo-code)? Because at the moment I think that it would be normal to extend this Teams interface in that case - and semantically that would mean that now this colors' set is dependent on colors object (or, as equivalent, its type) provided by base theme.
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.
Sure, let me provide an example. The text component in the base themes, specifies some color names, that may won't exists in the Teams theme (like blue for example). That means, that the interface that we use here will be different. For example:
//base theme:
interface TextVariables {
colorScheme: ColorSchemeMapping<ColorScheme, ColorNames>
}
//Teams theme:
interface TextVariables {
colorScheme: ColorSchemeMapping<ColorScheme, TeamsColorNames>
}
@@ -16,3 +21,23 @@ export const extendColorScheme = ( | |||
}) | |||
return result | |||
} | |||
|
|||
export function pickValuesFromColorScheme<T extends Partial<ComponentAreaName>>( |
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.
maybe simpler pickColors
name, given that arguments are descriptive enough?
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.
Hmm, it's not about picking colors is more about picking areas (like foreground, background)... So maybe pickColorAreas
would be better?
import { ColorScheme } from 'src/themes/types' | ||
|
||
export type TeamsContextualColors = { | ||
brand: ColorVariants |
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.
on ColorVariants
- currently this type is defined as type that any Stardust theme could use. However, we don't have any piece of Stardust code that relies on this structure (actually, good thing, as different themes might use different schemes to organise colors), and Teams is the only theme which uses it.
I think that it is logical to move this type from common to the types of Teams theme
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.
The base theme is using these typings as well. Yes is not required by any react specific file, but still is used in base theme..
type LabelColorSchemeMapping = StrictColorSchemeMapping< | ||
StrictColorScheme<LabelColorComponentAreas>, | ||
TeamsColorNames | ||
> |
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.
are we expecting this TeamsColorNames
set to change based on the component type? I think, we might start from exporting simpler StrictTeamsColorSchemeMapping<TComponentAreas>
type that would do this scaffolding in the background. This will make type interface being easier to client.
Also, we might want to rename this type to something like TeamsReducedSchemeMapping<TComponentAreas>
|
||
export interface LabelVariables { | ||
colorScheme: ColorSchemeMapping | ||
colorScheme: LabelColorSchemeMapping |
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 to be sure this is not overlooked - could you, please, suggest an example of this (like, some pseudo-code)? Because at the moment I think that it would be normal to extend this Teams interface in that case - and semantically that would mean that now this colors' set is dependent on colors object (or, as equivalent, its type) provided by base theme.
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'd need to deep dive to understand all the changes, let's chat in person
packages/react/src/themes/teams/components/Label/labelVariables.ts
Outdated
Show resolved
Hide resolved
packages/react/src/themes/teams/components/Menu/menuDividerStyles.ts
Outdated
Show resolved
Hide resolved
# Conflicts: # docs/src/views/ColorPalette.tsx # packages/react/src/themes/teams/colors.ts # packages/react/src/themes/teams/components/Label/labelVariables.ts # packages/react/src/themes/teams/siteVariables.ts
packages/react/src/themes/teams/components/Text/textVariables.ts
Outdated
Show resolved
Hide resolved
packages/react/src/themes/teams/components/Text/textVariables.ts
Outdated
Show resolved
Hide resolved
packages/react/src/themes/teams/components/Text/textVariables.ts
Outdated
Show resolved
Hide resolved
packages/react/src/themes/teams/components/Text/textVariables.ts
Outdated
Show resolved
Hide resolved
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.
👍 looks good to me, feel free to merge once comments from other reviewers are resolved
-replaced header prop in the ColorBox with copyToClipboardIcon
# Conflicts: # CHANGELOG.md
Things addressed in this PR:
In teams theme, we want to scope the color used to the ones actually defined in the theme (introduced generic for this)
We want from component's variables to export the parts of the color scheme only the areas actually used in the component. For example for the Label component, we are interested only in the background and foreground colors. (introduced two more generics for this, as well as stricter version of ones of the existing ones' introduced helper method:
pickValuesFromColorScheme
for making this easier for developers)removed
getColorScheme
, and usedgetColorSchemeKey
in order not to complicate too much the functions with generics that will have to be added by devs.renamed
emphasisColors
tocontextualColors
in Teams theme, as we have only the brand value there (we don't have primary and secondary colors) - open for other possible names here.added transparent colors in the color palette, those were added later in the process
added Not defined information on the Color Box for being more clear, rather then just showing transparent box