Fluentui: How to apply css styles to existing components

Created on 22 Nov 2018  ·  4Comments  ·  Source: microsoft/fluentui

Hi,

Every time I need to change a component style I wonder what's the proper way to do it.
Should I create a theme (createTheme), an IStyles object (eg.IButtonStyles), or something else?
For both these options, I always need to dig into the component's source code here on github to find out which properties I must specify.

I've just created this topic on stackoverflow detailing my question.

Thank you

JS Styling Theming Author Feedback No Recent Activity Question ❔

Most helpful comment

Current

  1. Use loadTheme to provide component wide colors and fonts.
  2. Use styles prop for components for one-off tweaks.
  3. If you'd like to provide a standard styles override for a specific component type, you can use Customizer to provide scopedSettings to pipe in standard overrides. (Not this is experimental and will likely change.)
  4. Legacy className / global css support still works, which is to use className to provide your own class overrides, and to reference global class names as needed. Though this is an option, this is is not recommended, as it's very fragile and suffers from numerous issues (selector specificity, no build time validation, easy to break, etc.) We're considering removing the global class names completely in a future major release.

In progress

Our goal is to move all customization into the theme; this lets you rev your design over time. We are tracking a bunch of work here: https://github.com/OfficeDev/office-ui-fabric-react/projects/26

The problems we've recognized

  1. Customizer for providing contextual overrides is too generalized, and doesn't allow us to have theme-specific logic like caching themes.
  2. ITheme should be expanded to allow you to pipe in component-specific overrides, in addition to other site-wide settings like sizing, shadowing, and animations.
  3. Passing in styles is not a good contract; you need to know which component parts to target for the styling (sometimes multiple parts) and sometimes which selectors to override (do i use a pseudo element here? is my selector not specific enough?)
  4. No support for color schemes (think the "dark header", where the Toggle should look different than in the "light content area".

Solutions to shortcomings

  1. Expose a dedicated ThemeProvider component. We will still have loadTheme for providing the default theme, while ThemeProvider can switch out scheme, or even theme in a box.

  2. Add support for color schemes.

  3. Introduce style variables, which abstract the common knobs from full styles definitions. This lets you not worry about parts or selectors, and simply focus abstractly on what the component should look like. We have this experimentally in our Button and Toggle refactors in experiments.

All 4 comments

I posted an reply. Hopefully that helps. Please feel free to close this issue if you believe your issue has been resolved.

@dzearing in case he has anything to add (and cc @micahgodbolt @Jahnp for the feedback about the documentation gap we have).

Current

  1. Use loadTheme to provide component wide colors and fonts.
  2. Use styles prop for components for one-off tweaks.
  3. If you'd like to provide a standard styles override for a specific component type, you can use Customizer to provide scopedSettings to pipe in standard overrides. (Not this is experimental and will likely change.)
  4. Legacy className / global css support still works, which is to use className to provide your own class overrides, and to reference global class names as needed. Though this is an option, this is is not recommended, as it's very fragile and suffers from numerous issues (selector specificity, no build time validation, easy to break, etc.) We're considering removing the global class names completely in a future major release.

In progress

Our goal is to move all customization into the theme; this lets you rev your design over time. We are tracking a bunch of work here: https://github.com/OfficeDev/office-ui-fabric-react/projects/26

The problems we've recognized

  1. Customizer for providing contextual overrides is too generalized, and doesn't allow us to have theme-specific logic like caching themes.
  2. ITheme should be expanded to allow you to pipe in component-specific overrides, in addition to other site-wide settings like sizing, shadowing, and animations.
  3. Passing in styles is not a good contract; you need to know which component parts to target for the styling (sometimes multiple parts) and sometimes which selectors to override (do i use a pseudo element here? is my selector not specific enough?)
  4. No support for color schemes (think the "dark header", where the Toggle should look different than in the "light content area".

Solutions to shortcomings

  1. Expose a dedicated ThemeProvider component. We will still have loadTheme for providing the default theme, while ThemeProvider can switch out scheme, or even theme in a box.

  2. Add support for color schemes.

  3. Introduce style variables, which abstract the common knobs from full styles definitions. This lets you not worry about parts or selectors, and simply focus abstractly on what the component should look like. We have this experimentally in our Button and Toggle refactors in experiments.

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for your contributions to Fabric React!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

luisrudge picture luisrudge  ·  3Comments

carruthe picture carruthe  ·  3Comments

prashkan picture prashkan  ·  3Comments

holysnake91 picture holysnake91  ·  3Comments

luisrudge picture luisrudge  ·  3Comments