-
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
FSE: Add a site title block. #33761
FSE: Add a site title block. #33761
Conversation
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. |
Outstanding thoughts, tasks, feelings: ❓Is hooking into the core editor state the best way of performing the site title update on publish? Does it make sense to use a different method? Is the existing ⬜ Styling needs to be re-worked to ensure it is consistent and properly applied. 💡Way down the line, we can genericize and HOC this functionality, if we go with a method similar to this. |
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/index.js
Outdated
Show resolved
Hide resolved
</svg> | ||
); | ||
|
||
if ( 'wp_template' === fullSiteEditing.editorPostType ) { |
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.
We can leave this check out for now for easier testing, while we sort out template plumbing.
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/index.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/index.php
Outdated
Show resolved
Hide resolved
Sweet! I can load the saved title, replace the title, then update the page, and have the new title display on the front-end 🎉 A few observations:
|
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/index.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
|
||
apiFetch( { path: '/wp/v2/settings' } ).then( ( { title } ) => { | ||
this.setState( { initialTitle: title } ); | ||
} ); |
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.
Hmm, I do wonder how often we should query. This is probably okay for now, but we might want to follow up on this.
Data here may get stale in a long editing session. We previously had problems with state, in Gutenlypso when switching sites, but it isn't a problem in this implementation.
For context in Calypso, we normally use a data pattern of a query component. example: https://github.com/Automattic/wp-calypso/blob/master/client/components/data/query-comment/index.jsx
The idea is make a request on mount, and any time related props change like site id.
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
} | ||
|
||
export default withSelect( select => { | ||
const { isSavingPost, isPublishingPost, isAutosavingPost, isCurrentPostPublished } = select( |
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 might poke around in core/editor state to see if there's an action we can listen to for the primary button click.
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
<PlainText | ||
className={ className } | ||
value={ title } | ||
onChange={ this.setSiteTitle } |
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.
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.
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.
Actually, the code view is showing the content that is saved: nothing 🙂(save: () => null
).
Remember that this is a dynamic block, so it is rendered by the server on the published view. Think of them like shortcodes. Wouldn't a shortcode allowing to override the site description look similar to that block syntax?
I admit the attribute is not strictly required when the post is saved (the back-end rendering will ignore the attribute and will retrieve always the description from the site data), but I don't know other way of letting the editor know there are changes that need to be saved.
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.
Let's tackle this next sprint in #34004
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.
Awesome! This is working great!
Left a few minor suggestions to fix some linter issues and another one regarding the custom classes support.
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/index.php
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.
LGTM!
Noted we're importing stuff from undeclared dependencies, so feel free to land this after adding them to the full-site-editing
's package.json
file.
*/ | ||
import { __ } from '@wordpress/i18n'; | ||
import { withNotices } from '@wordpress/components'; | ||
import { PlainText } from '@wordpress/block-editor'; |
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.
@wordpress/block-editor
should be declared as dependency of the full-site-editing
app.
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.
Let's stick with editor
for better support until it's actually removed (which already has its dependency declared): #33720 (comment)
import { PlainText } from '@wordpress/block-editor'; | |
import { PlainText } from '@wordpress/editor'; |
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.
Let's use the editor
package until support is dropped, block-editor was only added recently.
/** | ||
* External dependencies | ||
*/ | ||
import React, { Component } from 'react'; |
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.
react
should be declared as dependency of the full-site-editing
app.
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.
Actually, seems that import React
is not really needed. And we can import Component
from @wordpress/element
, making the react
dependency unnecessary.
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.
Highly advised to use the @wordpress/element
abstraction as it gives us better ways to handle compatibility cases (including mobile native) and avoids leaking too many assumptions.
@@ -0,0 +1,113 @@ | |||
/* 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.
Do we really need to suppress this rule? I'm not getting any linter error if I remove this line.
import { withSelect } from '@wordpress/data'; | ||
import { compose } from '@wordpress/compose'; | ||
|
||
/** |
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.
We can remove this comment since we're not importing any internal dep :)
This also needs a rebase before merging. |
if ( userInitiatedPublish ) { | ||
apiFetch( { path: '/wp/v2/settings', method: 'POST', data: { title } } ) | ||
.then( () => this.resetTitle() ) | ||
.catch( ( { message } ) => noticeOperations.createErrorNotice( message ) ); |
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.
Note that we need to render noticesUI
in the component in order to make this notice visible. See https://github.com/Automattic/wp-calypso/pull/33720/files#diff-ba2bdc4ff67c75de1773a2ef5e83c5eeR67
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.
Ahhh thanks for pointing that out!
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/edit.js
Outdated
Show resolved
Hide resolved
9300fbe
to
022317c
Compare
apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-title/index.js
Show resolved
Hide resolved
Nineteen styling.
Changes proposed in this Pull Request
A basic site title block for use with Full Site Editing
Testing instructions
Fixes #33106