Skip to content
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

Merged
merged 6 commits into from
Jun 19, 2019
Merged

FSE: Add a site title block. #33761

merged 6 commits into from
Jun 19, 2019

Conversation

jeraldjuice
Copy link

Changes proposed in this Pull Request

A basic site title block for use with Full Site Editing

Testing instructions

  • Open up your FSE environment.
  • Add a Site Title block in a FSE template.
  • Notice that the Site Title block reflects the site's title.
  • Update the Site Title and 'force dirty' the state by editing something else in the post contents.
  • Click "Publish..."
  • Refresh the page and notice that the site title has been updated.

Fixes #33106

@jeraldjuice jeraldjuice added [Feature] Post/Page Editor The editor for editing posts and pages. [Goal] Full Site Editing labels Jun 7, 2019
@jeraldjuice jeraldjuice requested a review from a team June 7, 2019 19:17
@matticbot
Copy link
Contributor

@jeraldjuice jeraldjuice self-assigned this Jun 7, 2019
@matticbot
Copy link
Contributor

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.

@jeraldjuice
Copy link
Author

jeraldjuice commented Jun 7, 2019

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 save function in the registerBlockType (site-title/index.js) a good hook instead?
❓ Will we need to handle non-publish save states in the future for the site title?

⬜ Styling needs to be re-worked to ensure it is consistent and properly applied.
⬜ Some refactoring needed.
⬜ More exploratory testing also needed.
⬜ Needs more sanitizing/validation for API calls.

💡Way down the line, we can genericize and HOC this functionality, if we go with a method similar to this.

</svg>
);

if ( 'wp_template' === fullSiteEditing.editorPostType ) {
Copy link
Contributor

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.

@kwight
Copy link
Contributor

kwight commented Jun 7, 2019

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:

  • It tripped me up that I couldn't directly edit the title text; I didn't realize the text was a placeholder. It might make more sense to load the actual text into the element.
  • Site titles should only be a single string of text; maybe an input tag instead of a textarea tag would make more sense? (This would align with what we use in the Customizer when editing the title.)
  • Since this is a visual preview, it can use some styling to fully match the front-end output (font size, color, etc – there also seems to be a blue border on focus, rather than the grey border other blocks seem to have).
  • Since the block has no attributes, any changes aren't persisted on drafts or autosaves – I think this is fine though (I don't expect users to be disappointed should the situation arise).

@gwwar gwwar added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. [Status] In Progress labels Jun 7, 2019

apiFetch( { path: '/wp/v2/settings' } ).then( ( { title } ) => {
this.setState( { initialTitle: title } );
} );
Copy link
Contributor

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.

}

export default withSelect( select => {
const { isSavingPost, isPublishingPost, isAutosavingPost, isCurrentPostPublished } = select(
Copy link
Contributor

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.

@jeraldjuice jeraldjuice requested a review from a team as a code owner June 12, 2019 17:20
<PlainText
className={ className }
value={ title }
onChange={ this.setSiteTitle }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to set a block attribute here with setAttribute in order to let the editor know that the content has changed. Otherwise the "Update" button will remain disabled until we change the content of other blocks:

Jun-13-2019 14-50-41

Copy link
Contributor

@kwight kwight Jun 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've got this working with attributes instead of local state for the value tracking. I admit I'm weirded out by the code view though; I really want whatever I see in the code view to coincide with what would get saved. If we never save attributes, should a user ever see them in the code view?

Screen Shot 2019-06-13 at 2 54 33 PM

Copy link
Member

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.

Copy link
Contributor

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

Copy link
Member

@mmtr mmtr left a 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.

@jeraldjuice jeraldjuice requested a review from a team as a code owner June 17, 2019 16:40
Copy link
Member

@mmtr mmtr left a 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';
Copy link
Member

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.

Copy link
Contributor

@kwight kwight Jun 18, 2019

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)

Suggested change
import { PlainText } from '@wordpress/block-editor';
import { PlainText } from '@wordpress/editor';

Copy link
Contributor

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';
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

@mtias mtias Jun 18, 2019

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 */
Copy link
Member

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';

/**
Copy link
Member

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 :)

@mmtr
Copy link
Member

mmtr commented Jun 18, 2019

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 ) );
Copy link
Member

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

Copy link
Author

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!

@jeraldjuice jeraldjuice force-pushed the add/fse-site-title-block branch from 9300fbe to 022317c Compare June 18, 2019 21:50
@kwight kwight changed the title [WIP] FSE: Add a site title block. FSE: Add a site title block. Jun 19, 2019
@kwight kwight merged commit e4136ad into master Jun 19, 2019
@kwight kwight deleted the add/fse-site-title-block branch June 19, 2019 22:10
@matticbot matticbot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Jun 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Post/Page Editor The editor for editing posts and pages. [Goal] Full Site Editing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Full Site Editing: Site Title Block [8]
6 participants