-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Block Library: Post Author: Refactor edit to use block context #22359
Conversation
Size Change: -113 B (0%) Total Size: 832 kB
ℹ️ View Unchanged
|
The changes here illustrate an interesting difference in the patterns, where Roughly, I think it's the difference of: Before: function MyComponent() {
const [ authorId, setAuthorId ] = useEntityProp( 'postType', 'post', 'author' );
} After: function MyComponent( props ) {
const { postType, postId } = props.context;
const authorId = useSelect(
( select ) => select( 'core' ).getEditedEntityRecord( 'postType', postType, postId )?.author ),
[ postType, postId ]
);
const { editEntityRecord } = useDispatch( 'core' );
const setAuthorId = ( nextAuthorId ) => editEntityRecord( 'postType', postType, postId, { author: nextAuthorId } );
} (Note: The former doesn't support context, or non-post post types) Part of me thinks that this is okay, and that it helps reaffirm and build consistent knowledge around selectors, action dispatchers, and the core data module in particular. On the other hand, maybe we don't need to abandon this convenience? I'm not sure if it could be built in to |
Co-Authored-By: Zebulan Stanphill <[email protected]>
Only now after merging, I have the sudden realization that this fails to account for the Site Editor, where there is no post 😩 I'll follow-up with something shortly. It's not entirely broken, per se, but it does try to present as if it were the block of a specific post. |
Maybe it's not worth worrying too much over right now. I don't know that restoring the text "Post Author Placeholder" is really any better 😄 If anything, this might be closer to what it should be in the case of a site editor representation of the block? As far as: Availability of block inspector controls, general markup structure (albeit likely stubbed with fake data or skeleton loader-esque styling). |
This is fixed by #22368. |
Previously: #21696
Related: #19894
This pull request seeks to refactor the Post Author block to use block context within the editor implementation, replacing
useEntityProp
with equivalent entity selectors / action dispatches operating from contextpostId
andpostType
values.Implementation notes:
A few general refactoring changes have been applied to the Post Author block based on comments at #19894 (comment), #19894 (comment), #19894 (comment).
The two components of the file have been merged to one. There was previous discussion of this at #19894 (comment). This was done largely out of removing this early return condition. I do not believe it should ever be the case that a post would not have an author associated with it. There may be a delay in loading details about that author, but we should still be able to render most of the elements of the block (inspector controls, etc). A placeholder, if applicable, could ideally be limited to just substituting the block list elements. Perhaps this could be split again to another smaller component, if necessary.
Testing instructions:
Repeat Testing Instructions from #19894, verifying there are no regressions in behavior.