CPT: Display notice when permanent deletion succeeds or fails

[aduth]

Related: #6306

This pull request seeks to cause a notice to be displayed after a request to permanently delete a post has completed, reflecting the success or failure of that request.

Testing instructions:

Verify that a notice is shown after a post permanent delete request finishes. You can force a delete failure by toggling the "Offline" throttle option in Chrome Developer Tools Network tab.

1. Navigate to the custom post types list screen
2. Select a site, if prompted
3. (Prerequisite) If Trashed filter is not available (because of no trashed posts), first trash a post
4. Select the Trashed filter
5. Under a post's action menu, select Permanently Delete and confirm your choice
6. Note that after the request completes, a notice is shown reflecting its success or failure

Test live: https://calypso.live/?branch=add/cpt-delete-post-notice

[mtias]

Do we need a link to the post in case of failure? Thinking if you delete three posts, navigate away on a slow connection, and and you get a single error, it would be hard to know which one failed.

[mtias]

Perhaps An error occurred while deleting "Post Name" with post name being a link.

[aduth]

@mtias It's like you're fully aware of the holes in adding actions via the notices reducer 😄 Namely in this case the fact that we don't have access to the post object in the delete dispatching.

The only ways I could imagine achieving adding a title and link to the notice would be either:

• Via the second explored option under Implementation notes in CPT / State: Display trash notice after save request completes successfully #6306, dispatching from component after separate reducer tracking request completion indicates an error. In fact, this may be worse for the scenario you described since it depends on the component originally dispatching the delete to stay mounted.
• Tracking post data in internal state for the notices reducer, as done in State: Update counts state in response to post status changes #6040. I wasn't a fan of it there, and it'd be even uglier here since notices generally are even further detached from posts than the counts reducer.

[mtias]

Can't you use the postId to grab the post from state in the reducer function?

[aduth]

Can't you use the postId to grab the post from state in the reducer function?

No, the state passed to the reducer is its local state, not the global state (which some claim is a good thing).

[mtias]

Fun, something seems to be amiss in the design of this then, either at the post actions level or the notices dispatching.

[timmyc]

navigate away on a slow connection

Looks like these notices are set to not displayOnNextPage so that part of the scenario might not matter, but could see the issue in deleting multiple posts from the list and one or more failing ( or eventually when bulk actions are added ).

I think another option for handling this would be to potentially add the failed deleted post back to the post list. Or do not remove it from the list optimistically. I believe we chatted about that idea before Andrew but wasn't sure if that was possible.

Code looks/works good for me in testing.

[mtias]

re: displayOnNextPage. That means the notice will show in the current page, but also that it could show on another page if you navigate, right? (At least that's how I think these should work.)

I think another option for handling this would be to potentially add the failed deleted post back to the post list.

Yes, if something failed the statuses should be reconciled and the posts re-appear. Though I wouldn't change how we optimistically delete it, because that's exactly how we want it to behave in offline mode, for instance.

In any way, we need to assume that the user may be looking at any page when the app learns an action failed, and we need to notify them.

[aduth]

Closing in favor of #6645