-
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
Apply the editor styles to the Site Editor page #20982
Changes from all commits
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 |
---|---|---|
@@ -0,0 +1,38 @@ | ||
/** | ||
* External dependencies | ||
*/ | ||
import { compact, map } from 'lodash'; | ||
|
||
/** | ||
* WordPress dependencies | ||
*/ | ||
import { useEffect } from '@wordpress/element'; | ||
|
||
/** | ||
* Internal dependencies | ||
*/ | ||
import transformStyles from '../../utils/transform-styles'; | ||
|
||
function EditorStyles( { styles } ) { | ||
useEffect( () => { | ||
const updatedStyles = transformStyles( | ||
styles, | ||
'.editor-styles-wrapper' | ||
); | ||
|
||
const nodes = map( compact( updatedStyles ), ( updatedCSS ) => { | ||
const node = document.createElement( 'style' ); | ||
node.innerHTML = updatedCSS; | ||
document.body.appendChild( node ); | ||
|
||
return node; | ||
} ); | ||
|
||
return () => | ||
nodes.forEach( ( node ) => document.body.removeChild( node ) ); | ||
Comment on lines
+31
to
+32
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. Related to #20982 (comment), I observe this unmounting behavior is "new", though again not entirely clear what impact (if any) it would have. One worry I might have is that since this unsubscribe behavior is called if any dependencies change, are we sure that 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 think so since these come from the server. It would surprise if this is the reason for the failure. The reason i added the unmount behavior is because it's the right thing to do if the styles changes, we need to recompute and reload them. |
||
}, [ styles ] ); | ||
|
||
return null; | ||
} | ||
|
||
export default EditorStyles; |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,7 +12,10 @@ import { Component } from '@wordpress/element'; | |
import { withDispatch, withSelect } from '@wordpress/data'; | ||
import { __ } from '@wordpress/i18n'; | ||
import { EntityProvider } from '@wordpress/core-data'; | ||
import { BlockEditorProvider, transformStyles } from '@wordpress/block-editor'; | ||
import { | ||
BlockEditorProvider, | ||
__unstableEditorStyles as EditorStyles, | ||
} from '@wordpress/block-editor'; | ||
import apiFetch from '@wordpress/api-fetch'; | ||
import { addQueryArgs } from '@wordpress/url'; | ||
import { decodeEntities } from '@wordpress/html-entities'; | ||
|
@@ -134,23 +137,6 @@ class EditorProvider extends Component { | |
|
||
componentDidMount() { | ||
this.props.updateEditorSettings( this.props.settings ); | ||
|
||
if ( ! this.props.settings.styles ) { | ||
return; | ||
} | ||
Comment on lines
-138
to
-140
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. Where did this condition go in the new implementation? Was it not needed? 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. Not needed cause we map through the styles but it can be micro-optim |
||
|
||
const updatedStyles = transformStyles( | ||
this.props.settings.styles, | ||
'.editor-styles-wrapper' | ||
); | ||
|
||
map( updatedStyles, ( updatedCSS ) => { | ||
if ( updatedCSS ) { | ||
const node = document.createElement( 'style' ); | ||
node.innerHTML = updatedCSS; | ||
document.body.appendChild( node ); | ||
} | ||
} ); | ||
} | ||
|
||
componentDidUpdate( prevProps ) { | ||
|
@@ -197,27 +183,30 @@ class EditorProvider extends Component { | |
); | ||
|
||
return ( | ||
<EntityProvider kind="root" type="site"> | ||
<EntityProvider | ||
kind="postType" | ||
type={ post.type } | ||
id={ post.id } | ||
> | ||
<BlockEditorProvider | ||
value={ blocks } | ||
onInput={ resetEditorBlocksWithoutUndoLevel } | ||
onChange={ resetEditorBlocks } | ||
selectionStart={ selectionStart } | ||
selectionEnd={ selectionEnd } | ||
settings={ editorSettings } | ||
useSubRegistry={ false } | ||
<> | ||
<EditorStyles styles={ settings.styles } /> | ||
<EntityProvider kind="root" type="site"> | ||
<EntityProvider | ||
kind="postType" | ||
type={ post.type } | ||
id={ post.id } | ||
> | ||
{ children } | ||
<ReusableBlocksButtons /> | ||
<ConvertToGroupButtons /> | ||
</BlockEditorProvider> | ||
<BlockEditorProvider | ||
value={ blocks } | ||
onInput={ resetEditorBlocksWithoutUndoLevel } | ||
onChange={ resetEditorBlocks } | ||
selectionStart={ selectionStart } | ||
selectionEnd={ selectionEnd } | ||
settings={ editorSettings } | ||
useSubRegistry={ false } | ||
> | ||
{ children } | ||
<ReusableBlocksButtons /> | ||
<ConvertToGroupButtons /> | ||
</BlockEditorProvider> | ||
</EntityProvider> | ||
</EntityProvider> | ||
</EntityProvider> | ||
</> | ||
); | ||
} | ||
} | ||
|
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.
Was there any consideration to make this a hook, considering its own behaviors are hooks? And observing that the current implementation forced refactoring of
EditorProvider
to render a fragment to support the additional top-level component.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 thought about it, the main reason I didn't do it is because
block-editor
don't expose hooks but expose similar behavior components like "ObserveTyping", "WritingFlow". I guess even this behaviors could be hooks.Now, that I think about it more, maybe a hook is better though.
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.
Yeah, I was thinking about these "behavioral" components as well. They made sense at the time. Nowadays, I feel that hooks are a perfect fit for how and why we were implementing those.
There's still an argument that could be made of "consistency for consistency's sake", so I could be okay with either approach.