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

Comment Content Block: Add typography, color and padding support #35183

Merged
merged 14 commits into from Oct 20, 2021

Conversation

DAreRodz
Copy link
Contributor

@DAreRodz DAreRodz commented Sep 28, 2021

Description

This PR continues the implementation of the Post Comment Content block that already existed. It adds support for text alignment, font size, family, style and weight, line height, colors (including links and gradients), and vertical/horizontal padding.

Will close #30574.

How has this been tested?

  1. Add a post comment block (using an existing comment ID).
  2. Add an inner post comment content block.
  3. Confirm that the color and typography options work.
  4. Confirm that the text align option works.
  5. Confirm that the padding option works.
  6. Create a template containing just the Comment Content block, and confirm that the fallback message (The content of the comment.) is shown.

Types of changes

Enhancement

Checklist:

  • My code is (manually) tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • I've tested my changes with keyboard and screen readers.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

@github-actions github-actions bot added the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label Sep 28, 2021
@github-actions
Copy link

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @DAreRodz! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

@mtias
Copy link
Member

mtias commented Sep 28, 2021

Commenting here but we should transfer to the general tracking issue — the "Post" prefix is a bit pointless, we should simplify the naming of all these blocks to be "Comment Content", "Comment Author" etc.

"lineHeight": true
},
"html": false,
"__experimentalLayout": true
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we will not need to add the __experimentalLayout for this block. Layout is for container blocks that enables controlling width/height.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, @ntsekouras. I did that because @SantosGuillamot suggested adding that specific setting. I'll talk with him to clarify that.

Copy link
Contributor

Choose a reason for hiding this comment

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

I suggested adding that because it's something supported in the Post Content block, and I thought it could be a good idea to follow a similar pattern. It seemed to me that it would add more flexibility for editing the layout, but I don't have a strong opinion here, so no problem if you feel it's better to change it 🙂

Copy link
Member

Choose a reason for hiding this comment

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

@scruffian @MaggieCabrera @jffng curious what has come up in themes as uses here.

Copy link
Contributor

Choose a reason for hiding this comment

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

I've not seen a real life use case where we'd want to use this outside of a post comment block.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think layout would make more sense in the parent blocks like Comment Loop

@jameskoster
Copy link
Contributor

jameskoster commented Sep 28, 2021

I understand that this happens when the comment ID is not specified in the parent block, am I right?

Correct. Example: editing the single post template in isolation, with no post data.

What should the block show when the comment ID is not correct? Is it OK showing the same message?

I presume you're referring to this interface in the current "Post Comment" block:

Screenshot 2021-09-28 at 15 44 26

I don't think we should offer this functionality in the Comment Content block since it is strictly a template-only block, IE it will always have an ID passed to it by the queried post.

Regarding the icon, I guess I have to create a new one inside @wordpress/icons using the design, right?

Perfect! Here's the SVG:

<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
<path fill-rule="evenodd" clip-rule="evenodd" d="M6.68822 16.625L5.5 17.8145L5.5 5.5L18.5 5.5L18.5 16.625L6.68822 16.625ZM7.31 18.125L19 18.125C19.5523 18.125 20 17.6773 20 17.125L20 5C20 4.44772 19.5523 4 19 4H5C4.44772 4 4 4.44772 4 5V19.5247C4 19.8173 4.16123 20.086 4.41935 20.2237C4.72711 20.3878 5.10601 20.3313 5.35252 20.0845L7.31 18.125ZM16 9.99997H8V8.49997H16V9.99997ZM8 14H13V12.5H8V14Z" fill="black"/>
</svg>

I'm not sure, but these settings don't seem quite possible to be added as that would modify the comment content, if I'm not mistaken.

Good point, these should probably be omitted :)

@ntsekouras
Copy link
Contributor

I don't think we should offer this functionality in the Comment Content block since it is strictly a template-only block, IE it will always have an ID passed to it by the queried post.

I agree with @jameskoster , but let's change this when we have the comments loop block. What do you think?

@jameskoster
Copy link
Contributor

jameskoster commented Sep 28, 2021

Hmm, this is a new block, no? So no harm leaving it out?

To be clear, we should keep that interface for the Post Comment block, but not have it for the Comment Content block.

Edit: I understand now. Imo we should update the Post Comment block to check the ID when the user adds it, and throw an "comment not found" error (or similar) if they input a bad ID.

@DAreRodz
Copy link
Contributor Author

Imo we should update the Post Comment block to check the ID when the user adds it, and throw an "comment not found" error (or similar) if they input a bad ID.

Makes completely sense, I'll do that. Thanks for all your feedback, guys. 🙌

@@ -15,13 +24,23 @@ export default function Edit( { context: { commentId } } ) {
'content',
commentId
);

// Show a placeholder when there is no context.
if ( ! commentId ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If no commentId exists the message should be something like no comment exists.
If content is undefined has two cases:

  1. still loading
  2. comment doesn't exist (this can be handled in a separate PR though and has to do with useEntityProp)

The below if ( ! content?.rendered ) check (I had hastily added yesterday) is not correct as it should be shown when the comment exists and there is no content.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If no commentId exists the message should be something like no comment exists.

Maybe (or probably 😅) I'm wrong, but from what @jameskoster wrote in this comment, I understood that, if you don't have commentId defined, it could be one of these two cases:

  1. You haven't defined commentId in the parent block (i.e., the Comment block). In that case, I assumed that the block responsible for showing a message like Input the comment ID would be the Comment block, and the Comment Content block wouldn't be rendered.
  2. You are editing a template / template part / etc. that would be rendered inside a Comment block. For this one, I thought you would see a generic message like The content of the comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If content is undefined has two cases:

  1. still loading
  2. comment doesn't exist (this can be handled in a separate PR though and has to do with useEntityProp)

I see. Is there a way to know if an entity is still loading or if it doesn't exist after calling useEntityProp? I mean, like a value or a prop returned by that hook? That would be useful. 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The below if ( ! content?.rendered ) check (I had hastily added yesterday) is not correct, as it should be shown when the comment exists and there is no content.

You mean that, if content is not defined, it's not that the comment has no content but that it doesn't exist, right? So I guess I should write something like if ( content && ! content.rendered ).

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess we could have a placeholder chip like here when no commentId is provided.

You mean that, if content is not defined, it's not that the comment has no content but that it doesn't exist,

Correct.

Probably there is a couple of things we could do for this first version, where we do not have the comment content editable - also not sure if we need to..

  1. Skip the check/placeholder for a comment that exists and has no content
  2. Instead of useEntityProp, use the core/data selectors like:
const { comment, isLoading } = useSelect(
	( select ) => {
		const { getEntityRecord, hasFinishedResolution } = select( coreStore );
		const queryArgs = [ 'root', 'comment', commentId ];
		return {
			comment: getEntityRecord( ...queryArgs ),
			isLoading: ! hasFinishedResolution( 'getEntityRecord', queryArgs ),
		};
	},
	[ commentId ]
);

@ntsekouras
Copy link
Contributor

Sorry for the temp close - bad gh cli command 😄

@DAreRodz
Copy link
Contributor Author

DAreRodz commented Oct 5, 2021

Hey there, I've just created a simple schema in order to organize things better in my mind. The following diagram shows how (IMHO) the Comment Content block should behave in the context of the Comment block.

Excalidraw link
image

While doing so, I came up with some questions:

  1. Maybe we can use the selector you proposed (Comment Content Block: Add typography, color and padding support #35183 (comment)) in the parent block instead, and handle there if we should render a loading/warning message when the entity is not ready or does not exist, skipping the children blocks. Would that make sense?
  2. If so, should those changes be done in a different PR?
  3. Am I overthinking here? Please, let me know. 😅

Apart from that, I've also been thinking about when the Comment block is rendered inside the Comment List block. In that case, I guess the Comment block should know whether it's being rendered inside or outside a Comment List. Is there a way for doing so, or would it need to be two different blocks?

Excalidraw link
image

@DAreRodz
Copy link
Contributor Author

DAreRodz commented Oct 6, 2021

I've done the changes that @ntsekouras suggested in #35183 (comment). About the placeholder chip, I guess I would need some help here from the designers (cc: @jameskoster ). 😊

Also, if anyone can take a look at what I've posted right before, that would be great. 👍

return (
<div { ...blockProps }>
<Warning>
{ __( 'The specified comment does not exist.' ) }
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should I change the warning message to include the block name? Just to make it more meaningful.

Suggested change
{ __( 'The specified comment does not exist.' ) }
{ __( 'Comment Content: The specified comment does not exist.' ) }

@jameskoster
Copy link
Contributor

jameskoster commented Oct 6, 2021

Hmm, I'm a little confused as to why we need this state:

Screenshot 2021-10-06 at 14 51 36

The UX is particularly poor because if I choose a bad ID when inserting the Post Comment block then I need to manually remove everything to start over.

Shouldn't we run the ID validation on this save button instead?

Screenshot 2021-10-06 at 14 53 04

If this "The specified comment does not exist." state is just an interim until we can do that, then I suppose it's ok. But ultimately I don't think a user should ever actually see this? 🤔

@mtias
Copy link
Member

mtias commented Oct 6, 2021

A comment could be deleted, or the ID could be modified using the html editor, or coming from a different template, WordPress import, etc.

@jameskoster
Copy link
Contributor

Makes sense. In that case I think it's ok for now, but we might want to revisit holistically later.

Just to clarify @DAreRodz, this is the "placeholder chip" you were referring to, correct? :D

@DAreRodz
Copy link
Contributor Author

DAreRodz commented Oct 6, 2021

Thanks for your feedback! 🙌

@jameskoster I agree with you: the ID validation should run on the save button of the Comment block (actually, it's more or less what I posted in the previous diagram 😅). I can implement it (if that's okay with you), although I'm not sure if it's outside the scope of this PR. 🙃

A comment could be deleted, or the ID could be modified using the html editor, or coming from a different template, WordPress import, etc.

@mtias good point, I didn't think of that. Wondering if it would make sense to show a similar message in the SSR from PHP. 🤔

Just to clarify @DAreRodz, this is the "placeholder chip" you were referring to, correct? :D

Nope, I was referring to this one I've added to show something while the comment is being loaded, as suggested in #35183 (comment), but he was proposing to use it when commentId is undefined. I've just realized I misunderstood what Tsekouras was proposing ― sorry about that. 🙈 I think he meant to use the "placeholder chip" here instead.

@jameskoster
Copy link
Contributor

jameskoster commented Oct 6, 2021

although I'm not sure if it's outside the scope of this PR.

Yeah let's do it separately.

I think he meant to use the "placeholder chip" here instead.

Ah, the no-context placeholder :D

There's an ongoing initiative to simplify the styling of these. The Post Content block for example just outputs a paragraph now. I think we can do the same here.

@mtias
Copy link
Member

mtias commented Oct 7, 2021

Wondering if it would make sense to show a similar message in the SSR from PHP.

It seems for actual rendering on the front it should skip doing anything if an ID is not matched?

@DAreRodz
Copy link
Contributor Author

DAreRodz commented Oct 7, 2021

It seems for actual rendering on the front it should skip doing anything if an ID is not matched?

It's what it does right now, I'll leave as it is then. 👍

@DAreRodz
Copy link
Contributor Author

DAreRodz commented Oct 7, 2021

I've updated the PR description to reflect the changes I've done. Not sure if there's anything I missed, so asking for reviewers. 🙂

@DAreRodz
Copy link
Contributor Author

I think everything is ready now. 😊

@gziolo gziolo self-requested a review October 19, 2021 09:48
Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

Code still looks good 👍🏻

@DAreRodz
Copy link
Contributor Author

Did I break something? There's a test failing that hadn't failed before. 👀

@gziolo
Copy link
Member

gziolo commented Oct 19, 2021

Did I break something? There's a test failing that hadn't failed before. 👀

It might be something with the env on CI:

Screen Shot 2021-10-19 at 12 04 32

We need to check other PRs to confirm.

Update: It's unrelated to this PR. I see the same issue in other places.

@jameskoster
Copy link
Contributor

I see, I'm using TT1 and it works fine with this theme. About CSS and priority, I don't know if there is a better solution than trying to make the CSS rules for type controls more restrictive ― which is far from a perfect solution as themes can use more restrictive rules as well. 🤷 I would love to read other opinions on this.

This is important to get right before merge imo, because in some rare cases none of these settings would work and the block would feel broken.

Ultimately if you're changing a setting on the block, it's because you don't like what is supplied by the theme, so I feel the block should take priority here if possible.

Oh, I guess you tried with an invalid commentId, am I right?

Correct :D It's working now 👍

@geriux
Copy link
Member

geriux commented Oct 19, 2021

Did I break something? There's a test failing that hadn't failed before. 👀

Hey there 👋 the fix for that issue is now merged into trunk

@gziolo
Copy link
Member

gziolo commented Oct 20, 2021

I see, I'm using TT1 and it works fine with this theme. About CSS and priority, I don't know if there is a better solution than trying to make the CSS rules for type controls more restrictive ― which is far from a perfect solution as themes can use more restrictive rules as well. 🤷 I would love to read other opinions on this.

This is important to get right before merge imo, because in some rare cases none of these settings would work and the block would feel broken.

Ultimately if you're changing a setting on the block, it's because you don't like what is supplied by the theme, so I feel the block should take priority here if possible.

I’m still unsure if that is a fixable issue with code. Block themes should leave the styling to blocks when it is supported. Maybe it’s only specific to a theme you tested with and we can sort it out by publishing a dev note for theme authors. They might be able to use theme.json to disable the UI controls if they have opinionated rules or remove those conflicting rules from CSS. It looks like the chicken or the egg dilemma 😅

@gziolo
Copy link
Member

gziolo commented Oct 20, 2021

It tests well when using TT1 blocks theme:

Editor:

Screen Shot 2021-10-20 at 13 05 12

Frontend:

Screen Shot 2021-10-20 at 13 05 21

@jameskoster
Copy link
Contributor

Maybe it’s only specific to a theme you tested with and we can sort it out by publishing a dev note for theme authors.

That seems fair.

@gziolo gziolo merged commit c3bf2f5 into WordPress:trunk Oct 20, 2021
@github-actions github-actions bot added this to the Gutenberg 11.8 milestone Oct 20, 2021
@DAreRodz DAreRodz deleted the add/comment-content-block branch October 20, 2021 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Comment Template Affects the Comment Template Block First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Comment Content Block
8 participants