-
Notifications
You must be signed in to change notification settings - Fork 583
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
fix(EMI-2224): Refactor Register to Bid flow #11522
base: main
Are you sure you want to change the base?
Conversation
🔥 🔥 🔥 🔥 🔥 🔥 🔥 🔥 🔥 🔥 🔥 🔥 |
setBiddingEndAt: Action<this, string | undefined | null> | ||
} | ||
|
||
export const getBidFlowContextStore = (): BidFlowContextModel => ({ |
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 is a great intermediate step especially for refactoring, later we can move all this logic to be pulled from MP to avoid having data not in sync and decouple further these screens
@@ -33,6 +32,8 @@ interface CreditCardFormProps { | |||
onSubmit: (t: Token.Result, a: Address) => void | |||
} | |||
|
|||
const MemoizedInput = memo(Input) |
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.
nice!. let's move this to palette-mobile though. This should be the default behaviour imo
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.
Or use formik?
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.
it is using formik 😅
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.
Oh i mean the Formik FastField component! https://formik.org/docs/api/fastfield
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 don't think it works on React Native since inputs are native elements 😢
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.
ahh dang 👍 all good
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.
didn't know about FastField
before. Thanks for sharing about it
035d663
to
ca4dbe5
Compare
Can't comment too much on the particulars, but amazing PR @MrSltun 🔥 |
import { Address, PaymentCardTextFieldParams } from "app/Components/Bidding/types" | ||
import { action, Action, Computed, computed, createContextStore } from "easy-peasy" | ||
|
||
type Increments = NonNullable<NonNullable<SelectMaxBid_saleArtwork$data["increments"]>[number]>[] |
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.
👍 👍 Thanks for pulling this from the generated type
</BiddingNavigationStack.Navigator> | ||
</NavigationContainer> | ||
) | ||
} |
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.
@MrSltun, @MounirDhahri - curious to get y'alls take here. (I'm mostly referencing Force and the ease in which we can discover most things, at a glance, just from viewing the file tree).
This bidding navigator is effectively an "app" with "routes", but its buried in components/containers
. While this follows existing patterns, its still quite confusing at a glance, when compared to how we can navigate all around in folio (as an imperfect example) and "see" the structure of the app just from the file tree (no need to look at code!).
It'd be great if we could lay down some patterns to help here, as i think it could naturally simplify the app and make it more tree like -- apps contain routes and screens; makes sense to colocate and make self-describing.
No need to address here! just figured this is a good example of what I mean and curious about y'alls take.
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.
Very good comment. I am going to add a comment about that to the practice mobile to discuss this together further as a team.
We could definitely do a better job in our documentation to limit the use of NavigationContainer
in Eigen. In almost all cases, it's not really required and if it's there, it's a symptom of high coupling.
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.
Decoupling the screens at the level of this PR might be so hard. I do though believe that these screens would benefit a lot from being decoupled from the context store that is wrapping them and be independent routes at some point in the future.
The main issue that made this screens hard to maintain, along with the navigation, is the state management and how it's being synchronized across the different screens. I believe the synching issue would be entirely solved if we make each of the screens an independent QueryRenderer
that queries for data itself instead of rely on other screens passing it. It will also give us more confidence in the future to make changes and make QA easier
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.
Great point! I think it makes sense to move it to navigation
instead of components/containers
since it's just a navigation container and not a component container, I will update that
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.
looks awesome, left some minor comments about some todos but other than that THANK you
// TODO: Clean up old code | ||
/* |
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.
👀
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.
Yeah I left those so it's easier to see the changes without breaking the GitHub diff, I added a note in the PR description about it 😅 but I will remove it before merging this PR!
} | ||
` | ||
|
||
// TODO: Clean up old code |
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.
👁️
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 is amazing! Great job.
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.
Awesome work 💪
Left a comment for future pr 🌮
onSubmit, | ||
billingAddress, | ||
navigator, | ||
navigation, |
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.
[future-work]: we should remove this drilling from navigation params between these components and rely on the navigation's hooks. Maybe the class components hinder us from doing it but we also can use withNavigation
HoC.
const backHandler = () => { | ||
if (canBidAgain) { | ||
return false | ||
} 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.
you don't need the else block here:
const backHandler = () => {
if (canBidAgain) {
return false
}
dismissModal()
return true
}
This PR resolves EMI-2224
Description
This PR fixes an issue with the credit card token not persisting in the app when bidding on an artwork before registering for the auction.
This also refactors the Auction registration flow to be able to add the fix, which should make the flow more performant (will add proofs later)
Note
I kept the old code for comparison and to not break the Github diff (hence the big addition and subtraction), but will remove it before merging this change
Would love your inputs on it :)
Tip
To review the code changes, I recommend chceking the commits of this PR
Videos
Videos Here
Before
register-no-cc-android-before-low.mp4
register-no-cc-ios-before-low.mp4
register-with-cc-android-before-low.mp4
register-with-cc-ios-before-low.mp4
bid-no-cc-android-before-low.mp4
bid-no-cc-ios-before-low.mp4
bid-with-cc-android-before-low.mp4
bid-with-cc-ios-before-low.mp4
After
register-no-cc-android-after-low.mp4
register-no-cc-ios-after-low.mp4
register-with-cc-android-after-low.mp4
register-with-cc-ios-after-low.mp4
bid-no-cc-android-after-low.mp4
bid-no-cc-ios-after-low.mp4
bid-with-cc-android-after-low.mp4
bid-with-cc-ios-after-low.mp4
PR Checklist
To the reviewers 👀
Changelog updates
Changelog updates
Cross-platform user-facing changes
iOS user-facing changes
Android user-facing changes
Dev changes
TODO
Need help with something? Have a look at our docs, or get in touch with us.