-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Try: Indicate when text color in post editor is inherited from Global Styles #55952
Changes from 2 commits
98c4c0d
735ea13
e81701f
b857070
40a4b4b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -32,6 +32,7 @@ import { | |||||||||||||||||||
default as StylesColorPanel, | ||||||||||||||||||||
} from '../components/global-styles/color-panel'; | ||||||||||||||||||||
import BlockColorContrastChecker from './contrast-checker'; | ||||||||||||||||||||
import { useGlobalStyle } from '../components/global-styles'; | ||||||||||||||||||||
|
||||||||||||||||||||
export const COLOR_SUPPORT_KEY = 'color'; | ||||||||||||||||||||
|
||||||||||||||||||||
|
@@ -293,6 +294,9 @@ export function ColorEdit( props ) { | |||||||||||||||||||
const { clientId, name, attributes, setAttributes } = props; | ||||||||||||||||||||
const settings = useBlockSettings( name ); | ||||||||||||||||||||
const isEnabled = useHasColorPanel( settings ); | ||||||||||||||||||||
|
||||||||||||||||||||
const [ userValue ] = useGlobalStyle( '', props.name, 'user' ); | ||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do think we need some kind of So yeah I wouldn't use the "global styles provider" and I guess in my mind, we need to introduce a new key to settings prop of BlockEditorProvider that should contain the global styles "styles" property (we only have settings right now) and use that property to build a block-editor version of Maybe I'm missing something here so would love to hear more thoughts. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes! This would certainly fulfill the needs of the current PR (and the larger styles inheritance UI system). I don't know enough to know if this potentially introduces any problems though. Btw, is there any overlap here with #55970 ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @michalczaplinski not necessarily, the problem here is a bit different than sharing the same code between edit-post and edit-site, we want access to the style hierarchy in the "block-editor" package. Until now, the block editor was only aware of the editor styles as CSS ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I dug here a little bit and these are the ideas I tried: 1. Create a
|
function useGlobalStylesUserConfig() { | |
const { globalStylesId, isReady, settings, styles } = useSelect( |
which in turn loads the global styles from the core-data
store:
gutenberg/packages/edit-site/src/components/global-styles/global-styles-provider.js
Lines 40 to 46 in 40a4b4b
const record = _globalStylesId | |
? getEditedEntityRecord( | |
'root', | |
'globalStyles', | |
_globalStylesId | |
) | |
: undefined; |
However, we cannot use the core-data
package in the block-editor
either...
2. Pass the data to the settings on the server
My second thought was to see if we can pass the required styles on the server in PHP in the block-editor-settings.php
. However, the Global Styles are loaded via the REST API so that's not an option either as far as I can tell.
3. Create a useStyles()
hook in the editor
package and use it in the edit-post
to inject the styles.
This approach looks the most reasonable to me as we can use core-data
in the editor
package. I opened a new PR in #59929 following this approach.
However, I'm still not sure if that's the best way to solve the problem:
- Having distinct logic for getting the styles in the
edit-site
andedit-post
does not seem ideal. - It seems a bit out of place to have styles-specific logic in edit-post/src/editor.js
I'd appreciate your guidance here @youknowriad! 🙏
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.
For me, the best approach is probably an additional "setting" to the settings prop of the BlockEditorProvider
.
- We have
__experimentalFeatures
(which we should probably rename at some point for the "settings" part of theme.json - We need the same but for "styles".
The problem is going to be the naming of these settings and I'm not the best person when it comes to naming things tbh 😬. cc @mcsf maybe
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.
@michalczaplinski you're right, sorry I missed this.
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.
No worries, I appreciate the guidance! I'm glad that we had roughly the same idea 🙂 We can continue to discuss in the PR.
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.
it is also possible to combine both "__experimentalFeatures" and styles in a single prop we could name
theme
maybe but I'm not sure entirely. I'd defer to others.
How about template?
More seriously, I think this should be an opportunity to inventory everything that goes into __experimentalFeatures
(as someone who isn't touching these pieces all the time, it's hard to remember what goes where). I think I'd favour a solution that strives for consistency with theme.json, since theme.json is already established as the dominant mental model that people need to get comfortable with, so we might as well piggyback off that.
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.
(Since the question was about naming, this was implicit but omitted in my comment: it would be nice to be able to express things in terms of styles
& settings
)
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.
How about template?
I'll do you one better: Template hooks 😄
Makes sense @mcsf. I've closed this PR in favour of #59929 which is the approach @youknowriad suggested. Let's continue to discuss there 🙂 .
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.
This is interesting, just noting that the "inheritValue" prop is a common prop to all the
*Panel
components and that in global styles for "block panels" it's possible to be set with the value set at the "root level" of global styles for instance.So basically, the behavior you're introducing here is also going to trigger in the global styles sidebar for blocks. I think that's probably fine but it's something to be aware of.
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.
yup, thanks for pointing that out! I noticed it as well, but I haven't tried to fix it at all yet.