Skip to content
This repository has been archived by the owner on Mar 4, 2020. It is now read-only.

chore(colors): Improve colors typings per component variables #1340

Merged
merged 29 commits into from
May 23, 2019

Conversation

mnajdova
Copy link
Contributor

@mnajdova mnajdova commented May 15, 2019

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 used getColorSchemeKey in order not to complicate too much the functions with generics that will have to be added by devs.

  • renamed emphasisColors to contextualColors 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

@codecov
Copy link

codecov bot commented May 15, 2019

Codecov Report

Merging #1340 into master will increase coverage by 0.05%.
The diff coverage is 69.23%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
...rk/components/Header/headerDescriptionVariables.ts 0% <ø> (ø) ⬆️
packages/react/src/index.ts 100% <ø> (ø) ⬆️
...emes/teams-dark/components/Label/labelVariables.ts 0% <ø> (ø) ⬆️
...c/themes/teams/components/Divider/dividerStyles.ts 16.66% <ø> (ø) ⬆️
.../teams-dark/components/Divider/dividerVariables.ts 0% <ø> (ø) ⬆️
packages/react/src/themes/teams/siteVariables.ts 100% <ø> (ø) ⬆️
...ams-high-contrast/components/Menu/menuVariables.ts 0% <ø> (ø) ⬆️
...themes/teams-dark/components/Menu/menuVariables.ts 0% <ø> (ø) ⬆️
...t/src/themes/base/components/Text/textVariables.ts 0% <ø> (ø) ⬆️
...s-high-contrast/components/Label/labelVariables.ts 0% <ø> (ø) ⬆️
... and 16 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e000bc8...62eb82b. Read the comment docs.

background: color,
foreground: 'rgb(232, 232, 232)',
},
brand: {
Copy link
Contributor

Choose a reason for hiding this comment

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

not sure if you were going to address this by the set of changes provided, but as a client I would expect that brand would appear under props of LabelColorSchemeMapping, so that at least types would suggest me that this is a safe thing to use:

image

Copy link
Contributor Author

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.

Copy link
Contributor Author

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,
Copy link
Contributor

@kuzhelov kuzhelov May 15, 2019

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.

image

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

Copy link
Contributor Author

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 = {
Copy link
Contributor Author

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

type LabelColorSchemeMapping = StrictColorSchemeMapping<
StrictColorScheme<LabelColorComponentAreas>,
TeamsColorNames
>
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 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.

Copy link
Contributor

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>

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 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.)

@mnajdova mnajdova changed the title [WIP] chore(colors): Improve colors typings per component variables chore(colors): Improve colors typings per component variables May 16, 2019

export interface LabelVariables {
colorScheme: ColorSchemeMapping
colorScheme: LabelColorSchemeMapping
Copy link
Contributor Author

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..

Copy link
Contributor

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.

Copy link
Contributor Author

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>
}

docs/src/views/ColorPalette.tsx Show resolved Hide resolved
packages/react/src/themes/colorUtils.ts Outdated Show resolved Hide resolved
@@ -16,3 +21,23 @@ export const extendColorScheme = (
})
return result
}

export function pickValuesFromColorScheme<T extends Partial<ComponentAreaName>>(
Copy link
Contributor

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?

Copy link
Contributor Author

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
Copy link
Contributor

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

Copy link
Contributor Author

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..

packages/react/src/themes/teams/colors.ts Show resolved Hide resolved
type LabelColorSchemeMapping = StrictColorSchemeMapping<
StrictColorScheme<LabelColorComponentAreas>,
TeamsColorNames
>
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Collaborator

@bmdalex bmdalex left a 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

# 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
Copy link
Collaborator

@bmdalex bmdalex left a 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

@mnajdova mnajdova merged commit b3782cf into master May 23, 2019
@delete-merged-branch delete-merged-branch bot deleted the feat/improve-color-mechanisms branch May 23, 2019 18:01
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants