Gutenberg Data Tutorial 5: Adding a Delete Button

[adamziel]

Description

This PR introduces the 5th part of Create your First App with Gutenberg Data tutorial – the focus is on deleting entity records.

Follows up on the fourth part: #39261 (sadly, the images aren't rendered properly there)

See the rich-text preview

[adamziel]

cc @getdave @scruffian @draganescu

[scruffian]

This looks good. A couple of ideas:

1. Hiding the item before the delete action has succeeded feels like a non-ideal pattern - what if the delete fails? What about changing the visual appearance of the line, rather than hiding it?

2. It would be good to have a screencast of the whole flow at the end.

[getdave]

Great work as always. Easy to read and to follow. Left some nits.

[draganescu]

Maybe for the sake of good practice we should use __( string ) for strings? Maybe it's too much for this tutorial tho.

[adamziel]

@scruffian have already mentioned that – I'd like to spin another PR to update all the parts of this tutorial at once.

[draganescu]

This is a bit confusing. Why not use a placeholder instead of this comment about the magic number?

[adamziel]

How would you introduce a placeholder that would clearly communicate that?

[adamziel]

I left the placeholder for now, I'm happy to revisit later on, though!

[draganescu]

Left a few nits but this is awesome otherwise!

[dmsnell]

Thanks for this great addition. One thing I noted is that the error handling code flashes an alert with useEffect( …, [error]) and I think that means we should expect an empty alert window when the error disappears. Might be best to try and omit any examples with alert() in them.

Alternatively we could use that to render a modal dialog, issue a toast when truthy, render an error message, or simply omit the rendering code for the example purposes.

Other than that I think these tutorials are getting so much more valuable 👍

[adamziel]

@dmsnell Hm I was sure I removed the alert() calls from this PR in favor of the snackbar notifications. Unless you mean this part still talking about useEffect?

const DeletePageButton = ({ pageId }) => {
	// ...
	const { error, /* ... */ } = useSelect(
		select => ( {
			error: select( coreDataStore ).getLastEntityDeleteError( 'postType', 'page', pageId ),
			// ...
		} ),
		[pageId]
	);
	useEffect( () => {
		if ( error ) {
			// Display the error
		}
	}, [error] )
	// ...
}

If so – great spot, I'll rework it to be consistent with the error handling code later in the same document.

[dmsnell]

if you removed it I might have missed it because I followed the link in the description, which referenced a specific commit, so maybe it referenced an earlier version of the PR.

the main thing was in that useEffect block when the error disappears the code runs again so as long as we don't make it seem like it only runs when there is an error it's all good. you may have already done this.

[adamziel]

It's already taken care of @dmsnell:

import { store as noticesStore } from '@wordpress/notices';
import { useEffect } from '@wordpress/element';
function DeletePageButton( { pageId } ) {
	const { createSuccessNotice, createErrorNotice } = useDispatch( noticesStore );
	// useSelect returns a list of selectors if you pass the store handle
	// instead of a callback:
	const { getLastEntityDeleteError } = useSelect( coreDataStore )
	const handleDelete = async () => {
		const success = await deleteEntityRecord( 'postType', 'page', pageId);
		if ( success ) {
			// Tell the user the operation succeeded:
			createSuccessNotice( "The page was deleted!", {
				type: 'snackbar',
			} );
		} else {
			// We use the selector directly to get the fresh error *after* the deleteEntityRecord
			// have failed.
			const lastError = getLastEntityDeleteError( 'postType', 'page', pageId );
			const message = ( lastError?.message || 'There was an error.' ) + ' Please refresh the page and try again.'
			// Tell the user how exactly the operation has failed:
			createErrorNotice( message, {
				type: 'snackbar',
			} );
		}
	}
	// ...
}