Skip to content
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

[NT-425] Manage Pledge Refresh #905

Merged
merged 8 commits into from
Oct 24, 2019
Merged

[NT-425] Manage Pledge Refresh #905

merged 8 commits into from
Oct 24, 2019

Conversation

ifbarrera
Copy link
Contributor

@ifbarrera ifbarrera commented Oct 22, 2019

📲 What

Refreshes the manage pledge screen when a user:

  • updates their pledge amount
  • changes their payment method
  • selects a new reward

🤔 Why

So that the updated pledge is reflected in the manage pledge screen when a change has been made.

🛠 How

Initially I was thinking the best approach would be to just refresh the backing when any change is updated. But after discussing with the Android team, it was brought up that it's nice to refresh the whole project in case rewards have changed. I decided to go with that approach based on that point.

👀 See

pSIe2lFmlU

♿️ Accessibility

N/A

🏎 Performance

N/A

✅ Acceptance criteria

  • Test update pledge: navigate to a backing that was created in the same environment that you are testing on. Then, navigate to "Update pledge" from the Manage Pledge screen. Change your pledge amount and tap "Confirm". You should be taken back to the Manage Pledge Screen and the amount should be updated.
  • Test update payment method: navigate to a backing that was created in the same environment that you are testing on. Then, navigate to "Change Payment Method" from the Manage Pledge screen. Change your payment method and tap "Confirm". You should be taken back to the Manage Pledge Screen and the payment source should be updated.
  • Test choose a new reward: navigate to a backing that was created in the same environment that you are testing on. Then, navigate to "Choose a new reward" from the Manage Pledge screen. Change your selected reward tap "Confirm". You should be taken back to the Manage Pledge Screen and the reward should be updated.

@@ -93,13 +93,6 @@ final class ManagePledgeViewController: UIViewController, MessageBannerViewContr
[self.pledgeSummarySectionSeparator, self.paymentMethodSectionSeparator, self.rewardSectionSeparator]
}()

static func instantiate(with project: Project, reward: Reward) -> ManagePledgeViewController {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This instantiate function was not being used.

@@ -245,8 +238,8 @@ final class ManagePledgeViewController: UIViewController, MessageBannerViewContr

// MARK: - Configuration

func configureWith(project: Project, reward: Reward) {
self.viewModel.inputs.configureWith(project, reward: reward)
func configureWith(project: Project) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can actually grab the reward directly from the backing and the project.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This centralizes how we retrieve the reward when the project refreshes (the reward is now always taken from the backing)

Copy link
Contributor

@justinswart justinswart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good so far, will deep-dive tomorrow!

- returns: A reward
*/

internal func reward(from backing: Backing?, inProject project: Project) -> Reward {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah nice 👍

I suppose this could also be a computed var on Project like backedReward: Reward?.

That said - if nothing is backed, it'll return Reward.noReward which doesn't seem correct, so I think the return type should be optional for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied and pasted this straight out of ProjectPamphletViewModel, but can update. I think ideally it would take a non-optional Backing and return a non-optional Reward.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also just realized I forgot to add tests for this 😅

@@ -99,13 +99,7 @@ public final class ProjectPamphletViewModel: ProjectPamphletViewModelType, Proje

let goToManagePledge = ctaButtonTapped
.filter { canShowManageViewPledgeScreen($0.0, state: $0.2) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this (and other) signals here would read better with something like:

.map { project, _, state in (project, state) }
.filter(canShowManageViewPledgeScreen)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I refactored all this 😅

@ksr-ci-bot
Copy link

1 Warning
⚠️ Big PR

Generated by 🚫 Danger

Copy link
Contributor

@justinswart justinswart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! This appears to work great. Approved with some minor suggestions.

Also, I was unable to test the third AC because that is something I'm currently fixing separately and that depends on work being done in #899.

Oh, also - of course this doesn't handle errors from the refreshing. I think that's fine for this? One would have to lose connectivity immediately after saving changes which is kind've an edge case. However if something did go wrong with the refreshing endpoint we wouldn't know about it.

Let me know if you think we should add error messaging for the refresh and I can re-review.

@@ -46,7 +46,7 @@ public protocol ProjectPamphletViewModelOutputs {

var goToDeprecatedViewBacking: Signal<BackingData, Never> { get }

var goToManageViewPledge: Signal<PledgeData, Never> { get }
var goToManageViewPledge: Signal<Project, Never> { get }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This output and related TestObservers really should just be goToManagePledge, I think we fixed this naming elsewhere but forgot to update it here 😬

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can update it 👍

|> Backing.lens.reward .~ Reward.noReward

let project = Project.cosmicSurgery
|> Project.lens.rewards %~ { rewards in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we just want to switch out the reward at index 0 we could write this here and in other places as:

|> Project.lens.rewards .~ ([Reward.noReward] + Project.cosmicSurgery.rewards.suffix(from: 1))

@ifbarrera
Copy link
Contributor Author

Nice! This appears to work great. Approved with some minor suggestions.

Also, I was unable to test the third AC because that is something I'm currently fixing separately and that depends on work being done in #899.

Oh, also - of course this doesn't handle errors from the refreshing. I think that's fine for this? One would have to lose connectivity immediately after saving changes which is kind've an edge case. However if something did go wrong with the refreshing endpoint we wouldn't know about it.

Let me know if you think we should add error messaging for the refresh and I can re-review.

Yeah this was a conscious decision – I figured that since we already show the "Got, it your pledge has been updated" message when the update request succeeds, it would be really confusing as a user to then see something like "Failed to get project" or "Something went wrong" because there's no context for the user around what actually failed. I felt it was best to fail silently, but open to discussing it. Fwiw Android also fails silently on refreshing the project.

@ifbarrera ifbarrera merged commit 1e3f58f into master Oct 24, 2019
@ifbarrera ifbarrera deleted the manage-pledge-refresh branch October 24, 2019 21:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants