-
Notifications
You must be signed in to change notification settings - Fork 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
SPT: Set template title in large preview #39831
Conversation
It implements a hacky solution to propagate the template title to the <PostTitle /> component, since it isn't possible to do it in thr current implementation of the component. I've created a PR, but in the meanwhile we can take this patch in order to give a quick solution. We can iterate later once the code PR is ship? WordPress/gutenberg#20609
This PR does not affect the size of JS and CSS bundles shipped to the user's browser. Generated by performance advisor bot at iscalypsofastyet.com. |
Caution: This PR has changes that must be merged to WordPress.com |
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.
Overall, this seems like a clever solution for being able to use the <PostTitle />
while waiting on an easier way to pass a string to the <PostTitle />
component 🙌
The only functional things I came across when testing in Chrome, Safari, and Firefox in multiple themes were:
- There's extra spacing underneath of the preview title compared to
master
Previously, the title was within the preview blocks, which meant the margins between blocks were collapsed. This title is outside of that block list, so the margins don't collapse and there's extra space.
- Safari shows the preview title in a faded color.
master
shows it in black, as expected.
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Outdated
Show resolved
Hide resolved
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Outdated
Show resolved
Hide resolved
...l-site-editing-plugin/starter-page-templates/page-template-modal/components/block-preview.js
Outdated
Show resolved
Hide resolved
...ng-plugin/starter-page-templates/page-template-modal/components/template-selector-preview.js
Show resolved
Hide resolved
...-plugin/starter-page-templates/page-template-modal/styles/starter-page-templates-editor.scss
Outdated
Show resolved
Hide resolved
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.
Thanks for this PR. I haven't manually tested this yet. Noticed some minor points when reviewing the code which I'm happy to discuss and help clarify.
My principle concern here is that we're introducing a hack which breaks React's data flow model. As soon as we start reaching into the DOM and tinkering we're introducing the very side effects that React is designed to avoid. This could lead to unintended consequences especially given that we're relying on a Core component which is subject to change in it's DOM structure...etc. In some ways the DOM isn't part of the component's public API so it is subject to change without warning which could break this implementaiton.
That said, I fully appreciate that this change is being viewed as a temporary workaround. That's ok if it truly is temporary. However, I have concerns about landing this unless we are confident that:
- the Core PR to set the
title
directly as aprop
will be accepted - can we get a Core team member to provide some indication of this? - our team will have time allocated in a future Iteration to come back and remove this hack with the "proper" solution
Thanks for exploring this and doing such a thorough deep dive 👍
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Outdated
Show resolved
Hide resolved
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Outdated
Show resolved
Hide resolved
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Outdated
Show resolved
Hide resolved
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Outdated
Show resolved
Hide resolved
...-plugin/starter-page-templates/page-template-modal/styles/starter-page-templates-editor.scss
Outdated
Show resolved
Hide resolved
…emplates/page-template-modal/components/block-iframe-preview.js Improve jsdoc. Props to @getdave :-) Co-Authored-By: Dave Smith <[email protected]>
…emplates/page-template-modal/components/block-iframe-preview.js Improve jsdoc. Props to @getdave Co-Authored-By: Dave Smith <[email protected]>
…emplates/page-template-modal/styles/starter-page-templates-editor.scss Set the CSS class name more targetted to the SPT scope. Co-Authored-By: Dave Smith <[email protected]>
57b43bd
to
8e087e4
Compare
8e087e4
to
437b03c
Compare
Totally agree. This is something that we should try to achieve with Frame |
I don't think so in the short term. I'd like to continue with this in my 20% time, 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.
This is looking much better. Thanks for all the improvements 👍
One thing I'd suggest is that we create a Calypso Issue now in our backlog to track the task for updating to use the update Core component if your Core PR to allow for a placeholder title
prop on the PostTitle
component is accepted.
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Show resolved
Hide resolved
|
||
// Exists as a pass through component to simplify automatted testing of | ||
// components which need to `BlockEditorProvider`. Setting up JSDom to handle | ||
// and mock the entire Block Editor isn't useful and is difficult for testing. | ||
// Therefore this component exists to simplify mocking out the Block Editor | ||
// when under test conditions. | ||
export default function( { blocks, settings, recomputeBlockListKey } ) { | ||
/* eslint-disable wpcalypso/jsx-classname-namespace */ |
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.
If we've updated to block-iframe-preview__template-title
do we need the eslint disable? It's better to keep these kinds of warnings where possible as (despite the "noise") they are the first line of defence against bugs.
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Show resolved
Hide resolved
...editing-plugin/starter-page-templates/page-template-modal/components/block-iframe-preview.js
Show resolved
Hide resolved
Can we create a new for this one? |
Changes proposed in this Pull Request
This PR improves how the template title is rendered into the preview. Now, it's a core/heading h1 block. What this PR proposes is to use the
<PostTitle />
core editor component.The only tricky part to deal is that this component gets the title from the post data. This is why we've created this PR in the core. In the meanwhile, however, we can go ahead in setting the template title using DOM manipulation. Once the core PR is ready 🤞, we can update and simplify the current approach.
Testing instructions
master
branchMayhood
before

after

Fixes #39805