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
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).
loadTheme to provide component wide colors and fonts.styles prop for components for one-off tweaks.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.)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.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
Customizer for providing contextual overrides is too generalized, and doesn't allow us to have theme-specific logic like caching themes.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.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?)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.
Add support for color schemes.
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!
Most helpful comment
Current
loadThemeto provide component wide colors and fonts.stylesprop for components for one-off tweaks.stylesoverride for a specific component type, you can useCustomizerto provide scopedSettings to pipe in standard overrides. (Not this is experimental and will likely change.)classNameto 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
Customizerfor providing contextual overrides is too generalized, and doesn't allow us to have theme-specific logic like caching themes.IThemeshould be expanded to allow you to pipe in component-specific overrides, in addition to other site-wide settings like sizing, shadowing, and animations.stylesis 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?)Solutions to shortcomings
Expose a dedicated
ThemeProvidercomponent. We will still haveloadThemefor providing the default theme, while ThemeProvider can switch out scheme, or even theme in a box.Add support for color schemes.
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
ButtonandTogglerefactors in experiments.