Fix backup codes screen status not updated if go back without checkbox confirmed

[renintw]

Fixes #190

This PR ensures that users cannot leave the Backup Codes screen by pressing Back without checking I have printed or saved these codes, and at the same time, prompt a Notice to remind users that they should confirm the checkbox before proceeding with other actions.

ScreenNavigation was extracted was done to make the subsequent commits easier to modify and read.

hasPrinted was extracted to useUser so that navigateToScreen can access it.

Screencast

No other errors in BackupCodes component exist

1.mp4

Other errors in BackupCodes component exist

2.mp4

Testing Steps

1. Test in a Sandbox.
2. enable 2fa.
3. Go to backup codes and you can't Back if you don't confirm the checkbox, and an error Notice should prompt.
4. Go to wp-content/plugins/two-factor/providers/class-two-factor-backup-codes.php and make it always throw an error on L295.
5. Go to backup codes and you can click Back.

[iandunn]

🤔 I have some reservations about this approach.

It seems like there's two things going on here:

1. The superficial issue is that the UI isn't updated automatically to reflect the current state after calling generatedCodes()
2. The deeper issues is that the upstream plugin implicitly saves/enables backup codes to the database before the user intends, but that's not how the design was created.

IMO, the design is correct, and the codes shouldn't be active until the user confirms they want to save them. That gives the user a choice whether or not they want to activate them, and makes sure they're aware that the codes are active.

This PR does make the user aware that they're active, but I worry that forcing them to stay on the screen will feel like a frustrating UX. It also doesn't achieve the goal of giving them a choice to cancel. Code-wide, I feels like this may add more complexity than we need.

I thought of a few potential alternatives:

1. Fix the UI state mismatch by calling refreshRecord() after the codes are generated

   -generateCodes();
   +await generateCodes();
   +await refreshRecord();

2. Remove the confirm checkbox from the UI for now, and replace it with a message indicating the codes are active. Then when Backup codes are saved before user intends two-factor#507 is fixed, we could bring it back.

3. Write our own API endpoint to generate backup codes, instead of calling the upstream API from the client. It could call the upstream endpoint internally, and then disable the backup codes immediately after. Then, when the user clicks confirm, our client would send another XHR to enable them.

If #1 would work, then that feels to me like the simplest option. We could also consider #2 if we want to go further.

I don't feel strongly though. What do you think @renintw and @adamwoodnz ?

[renintw]

but I worry that forcing them to stay on the screen will feel like a frustrating UX

I guess I wasn't aware of the case that if a user had already activated and saved a set of backup-codes, and then accidentally clicked the generate new backup codes button, or clicked it intentionally but then decided they didn't want new codes, this would be a frustrating UX like you said. In this case, the issue shouldn't be addressed by approach in this PR.

I'll open new PRs for #1 and #2, and extract the refactoring part in this PR that I think might be worth retaining.

Thanks for the feedback 🙏

Update

The problem seems to be solved in a different way in #217 and once WordPress/two-factor#507 is fixed, this issue The user should be able to enter the screen to see the status and regenerate codes, though. mentioned here could be fixed by changing this Line to disabled={ ! backupCodesEnabled && ! totpEnabled}

For extract the refactoring part, please see #215.

[renintw]

Closed. See #217 for potential solution.