Migrate Edit Navigation screen "Delete menu" button from confirm() …

[chad1008]

Related: #34153

Description

This PR aims to migrate the beta Navigation Editor's Delete menu button away from the current confirm() implementation and instead use the new experimental ConfirmDialog component.

How has this been tested?

Running WordPress 5.8.2 via wp-env:

1. Ensure the beta Navigation editor is activated from Gutenberg > Experiments
2. Open Gutenberg > Navigation (beta)
3. Create multiple menus (two or more)
4. Click the Delete menu button. Confirm there are no unexpected console errors and the new ConfirmDialog component is rendered instead of the browser's confirm() prompt.
5. Click the Cancel button. Confirm that the menu is still intact.
6. Click the Delete menu button again, and this time select OK
7. Confirm the menu in question is, in fact, deleted
8. Deleting one menu should automatically load the next menu that's in the database. Use Delete menu on all of them
9. Confirm that deleting the final/only menu returns you to the Create your first menu UI

Note, if you already have a menu saved from a previous session, attempting to delete it will result in an error. This doesn't appear to be related to this PR, and has been reported in #37794

I've tested in the latest Chrome, Firefox, and Safari.

Checklist:

• My code is 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).

[chad1008]

Marking as Draft - there's a bug when cancel is clicked on the ConfirmDialog that prevents future clicks of the Delete menu button from being registered. I'll investigate and reopen once that's fixed!

[chad1008]

Fixed - state is now handled more effectively, and the confirmation dialog is reset after the cancel button is clicked.

[chad1008]

Updated this PR to simplify the implementation of ConfirmDialog (cc @ciampo)

[ciampo]

Hey @chad1008 , thank you for working on this!

My feedback is basically the same as the one I left in PR 37491, including the consideration about unit/e2e tests.

[ciampo]

Update:

• I marked all of the memoization-related conversations as resolved for now, as discussed in this comment
• there's still an open comment that needs addressing
• not sure if you managed to look into fixing any broken e2e/unit tests (if any) and potentially adding any new ones

Even with the last comment addressed, I'd still be reluctant to merge this PR until we find a good fix for the z-index issue (see #37959).

[kevin940726]

Maybe we should await for onDeleteMenu() to finish? (I think it returns a promise?)

Bonus point if we can also catch errors here and display the message somewhere, but that's probably best for a different PR.

Another micro-optimization we can make is to show a loading state when the menu is still being deleted. Something like disabling the confirm button and showing a loading icon on the button. But again, probably best for a follow-up PR (I don't think it's possible now with the current API in __experimentalConfirmDialog anyway).

These are all just nitpicking though, I think we can merge this and work on those if needed.

[ciampo]

Maybe we should await for onDeleteMenu() to finish? (I think it returns a promise?)`

Hard to say for sure without any docs in this component.

I did a quick search in the codebase, and it looks like the only usage is in packages/edit-navigation/src/components/layout/index.js. In that case, the deleteMenu function comes from the useNavigationEditor() hook, and it is indeed an async function.

So yeah, we could technically

await onDeleteMenu();
setShowConfirmDialog( false );

Bonus point if we can also catch errors here and display the message somewhere, but that's probably best for a different PR.

Given the delete function definition, it looks like errors are handled via the createErrorNotice function, which seems to be connected to the notices store — I'm not familiar with what's the best "gutenberg" way to handle that?

Another micro-optimization we can make is to show a loading state when the menu is still being deleted. Something like disabling the confirm button and showing a loading icon on the button. But again, probably best for a follow-up PR (I don't think it's possible now with the current API in __experimentalConfirmDialog anyway).

We should have access to the loading state via the isMenuBeingDeleted prop passed to this component, but I don't think that the ConfirmDialog supports a way to disable its confirm button from outside the component (@fullofcaffeine can you confirm?)

[kevin940726]

c.c. @adamziel as this is a good example of lacking a clear and simple way to do loading state + error handling with the current API 😆 . (#38135)

[fullofcaffeine]

supports a way to disable its confirm button from outside the component (@fullofcaffeine can you confirm?)

You're right, that's not supported at the moment. I think it's a great improvement idea! What would that API look like do you think? A simple isLoading boolean prop that would disable the button and show a loading spinner when true?

[kevin940726]

A simple isLoading boolean prop that would disable the button and show a loading spinner when true?

Yeah, I think so. Since it should be a common feature, we can allow a simple prop like isLoading or disabled to do the job.

[ciampo]

A simple isLoading boolean prop that would disable the button and show a loading spinner when true?

I think I like the sound of isDisabled more as it is closer to what we want to achieve — disable interactions with the modal. Let's also add a is in front of the prop to make it clear that it's a boolean flag.

We also have to disable pressing the ESC key and clicking on the background, and we'll have to make this feature work both in controlled and uncontrolled mode. We can discuss further these details and refine the UX separately in the PR implementing the feature.

[ciampo]

Since this PR has been merged by @draganescu, let's add any remaining changes (potential e2e test improvements, and the points discussed in this conversation) in separate follow-up PRs (cc @chad1008 ).