-
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-1317] Show Rewards Based on Reward.isAvailable #2014
Conversation
44a9373
to
957ddee
Compare
// Both types of availability must be valid in order for this reward to be considered available. | ||
return limitedAvailabilityValid && timebasedAvailabilityValid | ||
public func rewardIsAvailable(_ reward: Reward) -> Bool { | ||
reward.isAvailable == true || reward.isNoReward |
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.
The no reward ("$1 Pledge without a reward") option is always available. The backend isn't controlling the isAvailable value for these, so I'm forcing it 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.
What do you think of setting isAvailable = true
when the no reward reward is created instead? That feels cleaner to me.
Tests are passing locally for me but not on CI 🤔 |
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, you should be able to have fewer isAvailable
setters now.
11a7ad0
to
2a7b398
Compare
e99566a
to
acc13fc
Compare
7f2f147
to
82d1d9a
Compare
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.
Re-recorded this snapshot to get it to pass. The only visible difference is the order, which by the looks of the original snapshot, wasn't correct to begin with.
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.
formatting changes that I can't seem to avoid. likely related to our discussion 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.
@scottkicks So you can avoid these, but it's a little annoying - unstage them from the commit, and instead do git commit -m "whatever your commit was" --no-verify
. My preference would be for us to solve this in its own PR, if we can, since it's such a weird and separate issue.
dfa1cdb
to
af65f22
Compare
af65f22
to
21bd8d3
Compare
@@ -163,8 +163,7 @@ private let cosmicSurgeryRewards: [Reward] = [ | |||
|> Reward.lens | |||
.description .~ | |||
"You will be the first to receive a copy of the book at this special ‘earlybird’ price. Limited to the first 100 copies." | |||
|> Reward.lens.localPickup .~ nil | |||
|> Reward.lens.isAvailable .~ true, |
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.
Forcing this reward to available seems to break the testRewards_Backer_LiveProject_Landscape.lang_es_device_phone5_8inch
test. Removing
* This is ok because we're testing that updated values don't impact whether rewards are shown or now. Just that they are shown with the correct data
func testConfigureWithProject_LocalPickupRewards_NonLocalPickupRewards_IncludiongNonLocalBackedReward_ShowsAllRewards_Success() { | ||
let rewards = Project.cosmicSurgery.rewards |
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.
also fixed a typo
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.
The changes LGTM but there are two things in here that should be pulled out.
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.
This change looks unncessary, can you pull it out?
@@ -26,7 +26,8 @@ extension Project { | |||
dates: Project.Dates( | |||
deadline: Date(timeIntervalSince1970: 1_475_361_315).timeIntervalSince1970 + 60.0 * 60.0 * 24.0 * 15.0, | |||
featuredAt: nil, | |||
launchedAt: Date(timeIntervalSince1970: 1_475_361_315).timeIntervalSince1970 - 60.0 * 60.0 * 24.0 * 15.0, |
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 you unstage this change from the PR? It's fixed in #2020
0587d00
to
48a3470
Compare
📲 What
Uses the isAvailable property on Rewards to determine reward availability and UI.
🤔 Why
Right now, unavailable late pledge rewards are being shown as available 👎
The expected UX is to show unavailable rewards, but they should be marked as such ("no longer available"), not tappable, and appear at the end of the rewards collection.
🛠 How
More in-depth discussion of the change or implementation.
👀 See
Unavailable rewards are marked as (no late pledge) in their title 😄
✅ Acceptance criteria