Block Library: Add a Post Comments block. #19581
Conversation
epiqueras
requested review from
ajitbohra,
jorgefilipecosta,
nerrad,
Soean,
talldan,
TimothyBJacobs and
youknowriad
as code owners
|
Added "design feedback" tag for designers to start thinking about the potential of these blocks (style variations, styling...) |
| } | ||
|
|
||
| export default function PostCommentsEdit() { | ||
| const postId = useEntityId( 'postType', 'post' ); |
There was a problem hiding this comment.
We may have other post types that support comments, for all these post types we are rendering 'Post Comments Placeholder' while I think we should render the same we render for posts (the comments in that post).
For post types that don't support comments but are not templates or template parts, I think we should not show the block on the inserter e.g: remove it from the allowed blocks or if we show in the inserter we should say in the block that comments are not supported. The block should handle the condition and show this message even if hidden from the inserter because a CPT may have supported comments in the past and then the user may disable the comments.
There was a problem hiding this comment.
This makes sense, but we'll have to handle it at another level in the code.
It will likely require changes to core-data to get post type capabilities and have CPTs act as posts under certain conditions.
There was a problem hiding this comment.
This is actually a very good remark and one that should lead to some rethinking in how the context EntityProvider and useEntityProp/useEntityId works.
Ideally, these hooks should just work no matter the CPT (all CPTs can have all properties) and should not have "post" hard-coded.
My first thinking here is that we should be able to do something like:
const entityId = useEntityId( 'postType' );
const entityContent = useEntityProp( 'postType', null, 'content' );
``
`
And these should basically return the first entity in the tree with the "kind" (postType)
We could even imagine a use-case for a post where we'd want any entity (less likely but why not)
const entityId = useEntityId();
const entityContent = useEntityProp( null, null, 'content' )
Too bad `useEntityProp` is a stable API now though cause "null" for the first and second args is not great.
There was a problem hiding this comment.
This is not the first block where it's specific to "post" so we need to solve this ASAP on a follow-up PR.
There was a problem hiding this comment.
Yes, this is what I suggested.
But, #19685 (comment) is my preferred alternative that also works on the server.
|
Can we merge this scaffold to avoid more merge conflicts in the shared files? |
ockham
force-pushed
the
add/post-comments-block
branch
from
b1de10f to
86589dd
Compare
|
Rebased. |
|
Size Change: +148 B (0%) Total Size: 857 kB
ℹ️ View Unchanged
|
noahtallen
force-pushed
the
add/post-comments-block
branch
from
d75fe1f to
1e21623
Compare
|
Rebased and added an entity label for Comments. |
In the future this should be editable
|
I added a "no comments" placeholder, as well as several TODO notes based on the feedback in the PR. I think the scaffolding for this PR is ready to go now 👍 |
Description
This PR adds a new Post Comments block akin to the Post Title and Post Content blocks.
How has this been tested?
Types of Changes
New Feature: There is a new Post Comments block for template building.
Checklist: