Theming: Add barHoverColor

[julien-deramond]

I've developed the following reusable Storybook theme for Orange a long time ago: https://github.com/Orange-OpenSource/ods-storybook-theme/blob/main/OrangeTheme.js.

The rendering can be seen live at https://boosted.orange.com/storybook/ (used in another project).

With the color palette that we usually use at Orange, I ended up being stuck for one use case (maybe due to the poor amount of colors in our palette 😁) where, as you can see, the actions bar has a black background but since our secondary color is black when you hover the action icons (or when they are active) they become black on a black background (so invisible).

What I did

In order to have an extra parameter to handle this specific use case, this PR suggests to add a barHoverColor in the interface so that this hover color could be modified when implementing a theme.

In the dark/white theme I set the default color to what's been used before; the secondary color.

For the active color, this PR suggests to change the color to theme.barSelectedColor that would seem more appropriate based on what I have tested (but IDK all the usages of the entire project).

First contribution

This is my first contribution. IDK at all the overall architecture so maybe this suggestion doesn't make any sense based on what already exists. I'm open to rework this PR with some guidance if there's a way to add some customization in the interface.

I struggled to find a way to test my modifications locally between https://storybook.js.org/docs/react/contribute/code and https://github.com/storybookjs/storybook/blob/next/CONTRIBUTING.md because of the @storybook/theming and ended up launching:

yarn start # First terminal
yarn build --all --watch # Second terminal

How to test

• Is this testable with Jest or Chromatic screenshots?
• Does this need a new example in the kitchen sink apps?
• Does this need an update to the documentation?

If your answer is yes to any of these, please make sure to include it in your PR.

[MichaelArestad]

This looks good to me. Thanks for making the PR. @shilman do you have anything to add?

[julien-deramond]

Not linked directly to this PR but I'm posting this question here so you have the context. If this PR is merged, do you mind if I try to extend what can be customizable in the theme? Or is it something you would like to limit voluntarily to a few customizable elements?

[MichaelArestad]

@julien-deramond Please propose some changes first and CC me so we can have a discussion. I would like to improve our theming system in general sooner than later and, to do that, it would help to know what types of things folks are interested in modifying. We may also change to a bit different system (perhaps CSS custom props?).

[julien-deramond]

Please propose some changes first and CC me so we can have a discussion. I would like to improve our theming system in general sooner than later and, to do that, it would help to know what types of things folks are interested in modifying.

From a general perspective, be able to theme the most things possible. Saying that is not very helpful, so having a priority order could be interesting.

IMHO I'd start with accessibility by allowing the configuration/theme to handle:

• Generic
  • :focus and :focus-visible behavior
  • texts and links colors and backgrounds: normal, selected, hovered, :focus, :focus-visible, etc.
• More specific
  • Sidebar (accordions)
    • "packages" colors
    • texts, icons and links colors and backgrounds: normal, selected, hovered, :focus, :focus-visible, etc.
  • Toolbar
    • background
    • texts, icons and links colors and backgrounds: normal, selected, hovered, :focus, :focus-visible, etc.

For companies/projects, it might be useful to be able to change the logo size (if not already possible).

Less important IMO, but it could also be interesting to handle the border rendering (colors, radius, etc.).

But I understand the complexity of handling all of that, it's almost like creating a generic highly customizable design system. I'm in the Bootstrap core team, and this is exactly what we're trying to do, and we end up with a ton of "design tokens" (Sass and/or CSS variables).

We may also change to a bit different system (perhaps CSS custom props?).

Yeah, it would probably be easier to use when creating themes or to modify on the fly with a simple stylesheet. And probably easier to maintain in Storybook source code. Moreover, people could define dark mode or any color mode more easily by switching the values of the custom props and even reuse the custom props defined in their own design system instead of setting some values in JS. The link between Storybook themes and design tokens defined by custom properties in projects/companies would be stronger.