-
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
Conversation
Size Change: -13 B (0%) Total Size: 857 kB
ℹ️ View Unchanged
|
This could use some reviews @vindl @Addison-Stavlo @johnstonphilip |
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.
Testing with the experimental 2019 blocks theme:
Front End:
Editor (pre-change):
Editor (post-change):
So the site editor now does display the styles in a way that is much more representative of the front-end (although not yet completely 1-1).
It looks like the Site Title block encounters an error with this change, is that expected at this point?
@youknowriad They are loading properly for me! Code looks good to me as well. @Addison-Stavlo The Site Title Block is working for me on this branch. |
Great! It works for me on master and as soon as i switch to using this branch I get warnings/errors stemming from SiteTitleEdit - Either way, its good to hear these changes work on your end without causing any sort of issue like that. |
@Addison-Stavlo That is super strange! The closest related issue I could find is this super old one so not sure if helpful: I wonder if it could even be that webpack had a hiccup or something? |
This mean we're trying to render undefined components. Looking at the SiteTitle block, it seems it was updated recently, so maybe just a branch switching workflow issue? |
Co-Authored-By: Andrés <[email protected]>
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 works nicely on practice and I very much welcome it to unblock #20530 👏 However, I'd like to get some eyes on a failing test before approving.
I can repro locally by:
npm run test-unit:native packages/edit-post/src/test/editor.native.js
It looks like ReactNative doesn't welcome the addition of the EditorStyles
component within the EditorProvider
. The message is a bit confusing because it suggests it can't find it but I've traced the export/import statements and they seem fine to me.
Perhaps @gziolo knows more?
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.
Ran the test locally and can confirm that it passes. The changes at 82c296c make sense now that I see that there's a separate export for native.
It's not immediately clear if or why it would be related, but I'm observing that every single commit to master since this (including this commit) have failed end-to-end tests; all but one with the following error:
I've never seen this failure before, nor do any of the previous commits (including failures) have this error.
See: #21177 |
*/ | ||
import transformStyles from '../../utils/transform-styles'; | ||
|
||
function EditorStyles( { styles } ) { |
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.
if ( ! this.props.settings.styles ) { | ||
return; | ||
} |
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.
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 comment
The 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
return () => | ||
nodes.forEach( ( node ) => document.body.removeChild( node ) ); |
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.
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 styles
will remain stable? Aside from my current debugging of test failures, seems like it might be a performance concern if the references change with any frequency.
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.
are we sure that styles will remain stable
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.
I'm not sure why this would fail these tests, but I'll try to debug tomorrow. |
@youknowriad It's fixed as of #21180. It may still be worth debugging, but the pressing issue (failing builds) is sorted for now. |
useEffect is async while componentDidMount is sync. that's the biggest suspicious thing for me. That said useEffect is recommended by the React team instead of the sync useLayoutEffect. |
Refs #20791
This PR loads the editor styles in the Site Editor Page to match the frontend.
Testing instructions