Automatic CSS Variable fallbacks (Components CSS) #24094
Conversation
ItsJonQ
added
[Type] Enhancement
| */ | ||
| import { stylisPluginCssCustomProperties } from './plugins'; | ||
|
|
||
| const createCustomCache = memoize( () => { |
There was a problem hiding this comment.
Technique suggested by a core Emotion member:
emotion-js/emotion#760 (comment)
|
Size Change: +5.49 kB (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
|
Update! I released the plugin code under my personal Github: The reason is because I want to have it available for personal use. If folks prefer, we can totally keep the plugin code within the project (leave this PR as is). Open to thoughts! |
|
Update! I've made some updates since the original PR. These updates include fixes to more accurately handle things like rgba and CSS shorthand. The package has 100% test coverage and I'm actively using it and maintaining it. I think it may be easier to use the package directly rather than have the code + tests in the project (for now). If that changes in the future, we can always copy/paste the necessary code into |
ItsJonQ
force-pushed
the
try/styled-provider-css-var-handling
branch
from
3afc743 to
d9f69b2
Compare
| */ | ||
| import createEmotionCache from '@emotion/cache'; | ||
| import { CacheProvider } from '@emotion/core'; | ||
| import stylisPluginCssVariables from 'stylis-plugin-css-variables'; |
There was a problem hiding this comment.
Code originally existed in this repo as part of this PR.
It was abstracted to a separate repo/package:
https://github.com/ItsJonQ/stylis-plugin-css-variables
|
cc'ing @saramarcondes Haiiiii!!! Continuing our convo from your other CSS-in-JS PRs 😊 . I think this StyledProvider will help smoother over CSS Variable fallback issues we talked about. Do you think you can take a quick look to make sure it works and the implementation feels okay? If so, maybe we can proceed with adding the resolver in there as well (perhaps as a hook within |
There was a problem hiding this comment.
Thanks for the PR @ItsJonQ I like the new automatic abstraction.
I don't like "Providers" in general because they make components less easily reusable but it feels that at least a single provider is mandatory to use the WordPress components and I wonder if should rename it to be able to add any addition providers required later to the same one.
| @@ -271,7 +272,7 @@ class EditorProvider extends Component { | |||
| ); | |||
|
|
|||
| return ( | |||
| <> | |||
| <StyledProvider> | |||
There was a problem hiding this comment.
This enables it for the post-editor (probably better moved to edit-post) but not for edit-widgets, edit-site, edit-navigation and list-reusabale-blocks (these are the top level packages).
- How do we make sure folks don't forget to add these providers?
- Is there a way to throw a warning if we detect a missing provider?
- Should we embed other providers there in a single one? (thinking about popover and slot providers).
- Should this be marked as a breaking change in the changelog of the components package?
Wonderful :) I do not like Providers either, especially if they are mandatory (which sometimes cannot be avoided). 🌄 BackgroundFor context, I revisited this PR because @saramarcondes started to graciously help out with components by refactoring styles to use CSS-in-JS. In doing so, she's run into a lot of roadblocks, many of which were things I've previously experienced. 🙈 RoadblocksThe primary roadblock would be converting the styles from Sass -> CSS-in-JS safely without introducing side-effects. This is quite tricky due to how (unexpected) coupled certain styles are. Well intentioned style rules that targeted deeper HTML elements (therefore raising specificity) that happen organically over time. That being said, these speed bumps are bound to happen regardless of we're doing a 1:1 Sass -> CSS-in-JS conversion or if we're doing something larger (like rewriting components like in G2 Components). 👉 Next StepsAfter some decision with @saramarcondes, we felt like it may be best to pause on some of the CSS-in-JS conversion and focus more on G2 Components (Sara, please correct me if I'm wrong). The reason is because many of the issues Sara and I have encountered were resolved within G2's Style System (if not 100% resolved, then at least something to allow us to strategically iterate). We've also been testing out integration strategies for G2 x Gutenberg. -- P.S. Back to Providers! In contrast, G2's Style System would not require a Provider to achieve this same effect, as the compiling via plugins (same basic technique) happens at a lower level. The only cause where a provider would be needed would be iFrame based rendering. |
|
Closing this up for now! Hopefully we'll be able get this from G2 Components. |
(Image shows a generated CSS declaration fallback for it's
var()usage inRangeControl)This is a follow up to:
#24059
This update adds automatic CSS variable fallback handling for CSS-in-JS generated styles from our
@wordpress/componentspackage (powered by Emotion).This is accomplished by combining a couple of parts:
✨ Stylis Plugin
Stylis is the light-weight, power, and fast (and awesome) CSS compiler that many CSS-in-JS libraries use (e.g. Styled Components, Emotion, Linaria, etc...). Stylis allows us to add custom middleware (aka. plugins) that can modify output. This pathway is enabled by Emotion with the creation of a "custom cache".
👩🎤 Emotion Provider (and custom cache)
Don't let the custom cache scare you. This is how Emotion works under-the-hood! We're creating our own cache instance (the brains that coordinates everything for Emotion) and syncing it with the components via a Provider.
This is the same technique I introduced in this PR:
#23215
(I'll need to update that one once this one merges)
🙏 IE Only Please
To optimize for performance, the transformations only occur on browsers that do not support CSS variables. The plugin auto-detects this by running a
window.CSS.supports()check.This option can be enabled/disabled by passing
skipSupportedBrowsers: falsewhen setting up the plugin:This is useful for tests (but also for debugging)
🍿 StyledProvider
This new
<StyledProvider />enables us to seamlessly enhance our CSS-in-JS workflow by using additional plugins.Some of these enhancements include...
How has this been tested?
Tested heavily with a barrage of unit tests. These unit tests throw wild (but valid) combinations of CSS variables, fallbacks, and odd value combinations to ensure that the parser works correctly.
The integration with the
<StyledProvider />(and generated styles) were tested manually in local Gutenberg (for both the editor and Site Edit).To test it locally...
skipSupportedBrowsers: falseto thestylisPluginCssCustomProperties()pluginnpm run devRangeSlidercomponentTypes of changes
cc'ing @diegohaz <3 (Just in case you're interested)
Checklist: