-
Notifications
You must be signed in to change notification settings - Fork 121
[IPPInAppFeedback] Orders screen banner placement #8640
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
Conversation
You can test the changes from this Pull Request by:
|
|
Great job @iamgabrielma! I added a few comments regarding the code. Is that something we have to fix? |
|
|
||
| /// Identifier for the In-Person Payments feedback survey | ||
| /// | ||
| case IPPFeedback |
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 thing here, if the enum type name already contains "Feedback", I think we can omit it here: case IPP, as in the case of the ordersCreation
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.
Changed on 83835c4
|
|
||
| if ServiceLocator.featureFlagService.isFeatureFlagEnabled(.IPPInAppFeedbackBanner) { | ||
| // TODO: Remove. Temporarily set to false so we can debug the IPPFeedback banner easily. | ||
| hideOrdersBanners = false |
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 find a bit dangerous to keep this in the PR, even if we add the TODO comment. If it goes to trunk it would disable the banner, which is not what we want
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.
You're right, that makes sense. I'll experiment with the @Published properties to find a better way to display/hide these.
I see we're using Publishers.CombineLatest(:) so the view model internal state figures out which banner should assign to the view, we could pass the $hideIPPFeedbackBanner binding as well there and use CombineLatest3(:) to figure this one out.
| loadOrdersBannerVisibility() | ||
|
|
||
| if ServiceLocator.featureFlagService.isFeatureFlagEnabled(.IPPInAppFeedbackBanner) { | ||
| loadIPPFeedbackBannerVisibility() |
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 have a question here, don't we load the orders banner if the IPP Feedback is enabled?
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.
Good question, after thinking further about it I was unsure how to fully deal with the Order Creation banner if IPP is enabled.
As per discussion at p1673883711765819?thread_ts=1673876649.359489&cid=C025A8VV728-slack-C025A8VV728 we're opting for:
- Prioritise showing the IPP survey. Show the Order Creation banner only when the IPP survey is not displayed.
- If IPP survey is dismissed, ideally we shouldn't show Order Creation immediately, unless that's the default behavior and changing it involves a certain level of complexity (as we're targeting to release this survey as soon as possible, then iterate later if needed).
| } | ||
|
|
||
| func dismissIPPFeedbackBanner() { | ||
| print("dismiss tapped") |
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.
Can we delete these prints here, as this is likely going to trunk?
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.
Definitely, removed on ff7a3ee
The IPP banner dismiss logic is not part of this PR. Removing for simplicity and to reduce scope.
|
Thanks for your review @toupper , I addressed the comments and this is ready for review again 👍
I missed that one! This UI tweak and others is something I'd leave for a different PR ( tracked here ), as we're using an existing component I wanted to work through its functionality first 👯 |
| .map { hasError, hasDismissedIPPFeedbackBanner, hasDismissedOrdersBanners -> TopBanner in | ||
|
|
||
| if hasError { | ||
| guard !hasError else { |
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.
So beautiful code 😉
|
Great job @iamgabrielma! Impressive how you are progressively tackling more complex features 👏 |

Closes: #8636
Part of: #8530
Description
This PR adds the in-app feedback banner to the Order view, as well as the buttons to launch a survey and dismiss the banner.
At the moment the banner is not dismissible. Dismiss will be part of a different PR.
Changes
.IPPcase as newFeedbackTypeOrderListViewController, we set the existing top banner view (generally used to display the Order Creation banner, or an error) to a new IPP banner survey. This uses the existingTopBannerViewandTopBannerViewModelcomponents.hideIPPFeedbackBanner, so we can listen to changes and set priorities on the different banners that should display in the view.ActionButtonthat will launch the feedback survey via the existingSurveyCoordinatingControllercomponent.Testing instructions
Screenshots
RELEASE-NOTES.txtif necessary.