Checkout Controller Sketch.#13290
Conversation
| fun confirm() { | ||
| controller.confirm() | ||
| } |
There was a problem hiding this comment.
Wondering if there are any issues with having this be top-level on CheckoutPresenter rather than a function on e.g. PaymentElement:
- Can you confirm if you are just showing a currency selector or shipping address element? It seems unlikely that you'd have a payment method to confirm?
- What if we wanted to provide different sets of confirmation definitions to different elements (e.g. maybe payment element and ECE have different confirmation definitions available to them)? This might be theoretical
There was a problem hiding this comment.
Where it lives is more of an API design choice I think. This is the public confirm, which should only affect selections made via payment element (I might be over simplifying this, but it's my current assumption).
We can use different confirmation definitions for ECE, and an entirely different confirmationHandler instance if we desire to -- but that should be implementation details. But again, probably over simplifying things in my head right now.
There was a problem hiding this comment.
which should only affect selections made via payment element (I might be over simplifying this, but it's my current assumption)
oh yeah this makes sense. Because other integrations either don't enable selecting a payment option (e.g. currency selector) or they handle confirm within their own ui (e.g. ECE)
|
|
||
| private lateinit var presenter: CheckoutPresenter | ||
|
|
||
| override fun onCreate(savedInstanceState: Bundle?) { |
There was a problem hiding this comment.
this impl feels like a pretty nice separation between business logic + UI!
There was a problem hiding this comment.
The roughest edge I see right now is how do we force the merchant to create the presenter? Maybe they have everything they need via the controller, until the user clicks a button to present/confirm. Which could be a failure mode.
There was a problem hiding this comment.
what's the failure mode exactly? is the merchant creating the presenter in the wrong place? I don't understand how they'd not create the presenter if they are accessing it later in their code
There was a problem hiding this comment.
The failure mode is they create the controller in the view model, and don't create the presenter unconditionally in onCreate. So it would basically be like in their "select a payment method" and "confirm" buttons -- they would do viewModel.createPresenter(this).makePaymentElement().presentPaymentOptions. But I think it's pretty easy to identify/fail during development. So maybe not a huge issue now that I write this out.
2 participants
Summary
Motivation
Testing
Screenshots
Changelog