[PAY-1934] Fix some issues with purchase modal state

[schottra]

Description

• Disallow closing of modal/drawer if a purchase is in progress. This required bringing the close handler logic back up to the modal/drawer level and using selectors for the purchase stage to know when a purchase is in progress.
• Added prop to NativeDrawer to allow blocking of the close action. Since we don't handle it directly, we need to signal to the component that is interacting with the slice that it should not close.
• Updated ModalDrawer and the mobile web drawer component to properly support the onClosed flow so we actually fire the cleanup actions after closing the modal/drawer on web/mobile web
• Fixed a silly mistake I made in the last PR where we would continue to show some of the form controls after the purchase is completed.

fixes PAY-1934

How Has This Been Tested?

Tested locally in simulator, web, mobile web emulator against staging

[rickyrombo]

Was noticing on mobile the PurchaseDrawer doesn't get notified that the StripeDrawer closed early/unexpectedly. It looks like these are mostly web changes to prevent the modal from closing though, right? Just making sure we don't brick mobile PurchaseDrawer if you exit the StripeDrawer

[rickyrombo]

nit: prefer non-early return here imo

[schottra]

Oh interesting I usually feel the other way! What's the reasoning behind wrapping it all in a conditional?

[rickyrombo]

at a glance you know the two other methods are fired conditionally, vs having to have the whole fn context. I go either way based on the context - here I think the method is short enough that it makes sense to just use the conditional block. I tend to use early returns in arg validation scenarios and when the block is super large

[schottra]

Was noticing on mobile the PurchaseDrawer doesn't get notified that the StripeDrawer closed early/unexpectedly. It looks like these are mostly web changes to prevent the modal from closing though, right? Just making sure we don't brick mobile PurchaseDrawer if you exit the StripeDrawer

@rickyrombo The logic at the moment for blocking close is !error && isContentPurchaseInProgress. I had thought that we set an error when you cancel the stripe flow early. But you are correct that if we don't catch that and update the state, this might now be bricking things :-(

[schottra]

Was noticing on mobile the PurchaseDrawer doesn't get notified that the StripeDrawer closed early/unexpectedly. It looks like these are mostly web changes to prevent the modal from closing though, right? Just making sure we don't brick mobile PurchaseDrawer if you exit the StripeDrawer

@rickyrombo The logic at the moment for blocking close is !error && isContentPurchaseInProgress. I had thought that we set an error when you cancel the stripe flow early. But you are correct that if we don't catch that and update the state, this might now be bricking things :-(

Makes sense! Thanks for explaining