refactor(Divider): remove type prop

[layershifter]

Fixes #421.

BREAKING CHANGES

We decided to drop type prop on this component because type is a reserved prop in HTML.

Before

<Divider type='primary' />
<Divider type='secondary' />

After

<Divider color='primary' />
<Divider color='secondary' />

[layershifter]

I aligned code in these examples.

Before

After

[mnajdova]

👍

[levithomason]

@layershifter I just merged prettier integration #568 which auto formats CodeSnippets and ExampleSnippets. It also removes the need to have the value string prop altogether by printing the render prop return value and prettifying it 👍

Just fix conflicts here to account for that.

[mnajdova]

Not sure how would this reflect the fact that we want to show the examples as Javascript code, but we are writing the actual rendered code in Typescript... I have something like this in the Integrate Custom Components guide. What is the proposal for addressing this?

[layershifter]

I decided to remove Divider from theming examples because we using color palette there and examples will be overcomplicated (current and previous pattern).

After we will apply color palette to all our components we will return Divider.

[mnajdova]

👍

[levithomason]

TIL: Record

[mnajdova]

What is the magic '500' doing here? :)

[layershifter]

We have colors with following structure:

const colors = {
  blue: { 500: 'blue' // other values },
  pink: { 500: 'pink'  },
}

I decided to reduce this structure with mapValues to as we using only single variant:

const colors = {
  blue: 'blue',
  pink: 'pink',
}

This structure is more usable for overrides, too.
Yes, it looks like a magic number, but it is a simply color variant.

[layershifter]

We can do this:

const colorVariant = '500'

return {
  colors: _.mapValues({ ...siteVars.emphasisColors, ...siteVars.naturalColors }, colorVariant),
}

May be, this change will improve readability.

[levithomason]

We can save my comment here for another PR, but here are some thoughts.

---

Wondering if we should go this route, defining single color variable for every component. Most components will implement the same variant of a color for the same purpose. Example, a blue border will be the same shade in components that have blue borders. Red text is similar where ever it appears. The odds that a specific component needs to override a specific shade of color I think would be the exception and not the norm.

We might be able to produce a "scheme" for a component to implement. Imagine picking colors along a color object like this:

const primary = {
  50: '#F4F4FC',  // background
  100: '#E2E2F6', // shadow
  200: '#BDBDE6', // border
  300: '#8F90C1',
  400: '#6E70AE',
  500: '#6264A7', // text
  600: '#55578D',
  700: '#4A4C78',
  800: '#414265',
  900: '#33344A',
}

Or, an inverted version of the same component using different variants from the same object:

const primary = {
  50: '#F4F4FC',  // text
  100: '#E2E2F6',
  200: '#BDBDE6', // shadow
  300: '#8F90C1',
  400: '#6E70AE',
  500: '#6264A7', // background
  600: '#55578D',
  700: '#4A4C78', // border
  800: '#414265',
  900: '#33344A', 
}

Divider

Applied to the Divider, I can imagine variables for the borderColor and a textColor since these are the relevant parts of the component and can have different colors, such as here:

However, I think what is missing in this PR right now is that there is no indication of which variant the text color will use compared to the border variant. We might want a way to choose a "scheme" for applying to a component or at least specify which variants will be used.

Schemes

If we try the scheme route, we might look at many components in a UI and ask what the common color schemes are. A scheme would includes colors for text, background, border, and shadow.

I can see defining a "primary" scheme or a "secondary" scheme, even "inverted" schemes in this way. The scheme from the first Message looking component above would look something like this:

const scheme = {
  foreground: primary[500],

  quiet: primary[400],         // range of "muted" foreground colors
  quieter primary[300],
  quietest: primary[200],

  background: primary[50],
  border: primary[200],
  shadow: primary[100]
}

These could be generated for any color, inversion, emphasis, and state like disabled. They could also be adjusted for higher/lower contrast or brightness.

[layershifter]

Yes, it's a long discussion :) Not for this PR, that's why I removed Divider from examples of theming.

[mnajdova]

@layershifter yep, please introduce the changes proposed in #558 (comment) it is much clear that way.

[mnajdova]

👍

[bmdalex]

@layershifter can we extract this interface
Record<keyof (EmphasisColors & NaturalColors), string>
in src/themes/types.ts to reuse it for other's components color prop?

[bmdalex]

@layershifter can we extract this method
_.mapValues({ ...siteVars.emphasisColors, ...siteVars.naturalColors }, colorVariant),
or even an object if the colorVariant is always 500
export themeColors = _.mapValues({ ...siteVars.emphasisColors, ...siteVars.naturalColors }, 500)
to reuse it for other's components color prop?