-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MBL-1422] Handle errors without always dismissing #2090
Conversation
case bannerAndParentVC | ||
} | ||
|
||
private var dismissType: DismissType = .bannerOnly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't add any new tests around dismissType - I don't think our code is structured to make it easy to capture when view controllers dismiss in tests (please correct me if I'm wrong about that!). Alternatively, I could move all the dismiss logic into the view controller, but that would be a bigger refactor than I was hoping for. Open to suggestions here!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Are we confident that we don't need to create a new checkout from Confirm Details after this error. I'm like 90% that's true, but I tend to get paranoid in this flow 😅
case bannerOnly | ||
// Banner can be dismissed by the user and will be dismissed automatically. | ||
// Once the banner is dismissed, the presenting view controller is popped. | ||
case bannerAndParentVC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor nit: maybe bannerToParentVC
is a clearer name for this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've renamed this to just bannerAndViewController
- I think that we were thinking of the "parent vc" differently (in my mind it's the view controller that's getting dismissed, since it's the parent of the message banner). I think the new name is clearer for both of us!
I double-checked the code and we don't even give stripe the checkout id when we're adding a new card (we give the project and late pledge vs crowdfunding pledge context), so there's no reason to go recreate the checkout id if adding the card goes wrong! |
📲 What
Don't dismiss the post campaign VC if there's an error caused by trying to add a new card.
Note: There are other categories of errors that also don't need to dismiss the VC (for example, if a user fails to authenticate a 3DS card). However, because we're currently planning to combine our checkout flows and get rid of the "confirm details" page, I didn't think it was worth spending a lot of extra time on this now.
🤔 Why
Needing to restart checkout in these cases is a little annoying.
🛠 How
I refactored the messageBannerView to optionally be in charge of dismissing the vc. That way, we can decide if the error should lead to dismissing the VC when a specific error is displayed to the user.
👀 See
Jira
✅ Acceptance criteria