-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global Styles #19814
Global Styles #19814
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is WIP; just pointing out some minor things I noticed.
speedy: true, | ||
} ); | ||
|
||
export const getGlobalStylesSheetAsCssStringSync = () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this and the following functions should use standard named function declarations rather than anonymous functions, since named functions show their names in stack traces, making debugging easier. There's no reason for these to be anonymous functions, as far as I can tell. In fact, I think a standard function declaration would use fewer characters in this instance.
didRegisterRef.current = true; | ||
}; | ||
|
||
export const useSetBlockCssProperties = ( ) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found an unnecessary space between the parentheses here.
Follow up: #19611 (comment) |
@ZebulanStanphill Thank you so much for taking a look! I really appreciate your enthusiasm for this project! I think I'm going to close up this Draft PR. @nosolosw , @jorgefilipecosta, and I synced up today to figure out a plan moving forward. What we have follows a similar design, but the initial implementation will be different :). More here: |
This is a draft pull request for the upcoming Global Styles focus for Gutenberg.
This work complements the efforts of Full Site Editing to provide users with a richer experience in customizing the aesthetics of their site.
State of code
(as of 2020-01-22)
The current implementation is incredibly rough. It was simply a means to test out the mechanics (described below). The code will evolve a lot as we start developing the various parts of the system.
Concept ✨
Global styles is a system makes it easier for users to reliably design and stylize their sites. It provides a foundation for Gutenberg Blocks, Themes, and Customizations to work together.
Demos
Mechanics
The primary mechanics of Global styles are:
Loader
Loader interacts with a theme by first finding a
theme.json
. This.json
file contains configurations (Design Tokens) that stylize the site.State Management
Gutenberg uses a heavily modified version of Redux in their @wordpress/data package. Global styles' state management will be part of this data store. This allows the global styles data to be accessed, shared, and manipulated across all of Gutenberg. From a Global Styles Editor, to individual blocks.
Transformers
Transformers immutably adjust the data from the store, making it easier to consume. Global styles expose a transformers plugin system, allowing for the data to be modified or interpolated to generate more values.
For example, a single colour value, auto-generating 6 colour variants.
Controls
Controls exist within the Global Styles editor. They provide a UI (e.g. range sliders, colour pickers) that allow the user to directly manipulate global style values. This experience replicates that of
InspectorControl
from@wordpress/components
, which is the current established pattern from updating blocks within Gutenberg.Hooks
(Custom) Hooks allow for Gutenberg blocks to have access to global styles. These hooks should feel very light weight to use. Most of the heavily lifting of accessing, consolidating, and transforming data will be handled by the "Transforms" mechanic.
Renderer
The Renderer outputs the global styles (prepared by Transformers) into the DOM, for both Gutenberg editor (block "edit") and the "frontend" of the site (block "save").
Within Gutenberg, anytime a custom style (global, document or block) is updated, the Renderer needs update the styles in real time.
For "frontend" site rendering, it is preferred that there is no style computation/consolidation required on runtime. This can be accomplished by pre-saving a generated HTML output during editing.
The desired implementation is to use CSS Variables, which gives us native interpolation and scoping features.
However, potential alternatives may include working directly with a CSSStyleSheet instance, a managed CSS className system, or anything in between.
Inspirations
State Management, Transforms, Renderer
Inspiration for these mechanics come from the internals of popular CSS-in-JS libraries like Emotion.
Internally, most of these libraries use Stylis for CSS pre-processing. Stylis has a plugin system, allowing for authors to customize style output as required. This feature inspired the plugin system for Transformers.
The way libraries like Emotion coordinate style updates + re-renderings inspired some of the ideas within the State Management and Renderer mechanics.
Style Hierarchy
The Style Hierarchy of Core, Themes, Global, Document, Blocks was inspired by the "Inverted Triangle" design principle from ITCSS.
Some of the borrowed concepts focus on style layering and the unidirectional flow of specifity (overrides).