-
Notifications
You must be signed in to change notification settings - Fork 117
WIP: Extract card reader connection state management from App to Yosemite #12723
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
…Yosemite framework.
…cies from App to Yosemite.
…ecessary parameters in the UI state.
Generated by 🚫 Danger |
|
@@ -1,13 +1,68 @@ | |||
import Combine | |||
import Foundation | |||
import UIKit | |||
import Storage | |||
import SwiftUI |
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.
We can also remove the SwiftUI import from here to assure that we have no UI-related stuff going on, at the moment it still compiles fine when we do 👍
import Storage | ||
import SwiftUI | ||
import Yosemite | ||
|
||
public enum CardReaderConnectionResult { |
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 know this is from before, but should we use a different name for this enum? *Result
implies there's a result type to be expected, which is not the case, and later we find signatures like:
private var onCompletion: ((Result<CardReaderConnectionResult, Error>) -> Void)?
Perhaps something like CardReaderConnectionStatus?
alertsPresenter: CardPresentPaymentAlertsPresenting, | ||
alertsProvider: BluetoothReaderConnnectionAlertsProviding, |
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.
💯
state = .idle | ||
knownCardReaderProvider = knownReaderProvider | ||
self.alertsPresenter = alertsPresenter | ||
self.alertsProvider = alertsProvider | ||
foundReaders = [] | ||
knownReaderID = nil | ||
skippedReaderIDs = [] |
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.
Since we're cleaning up the init here, maybe those should also go into some sort of "initial state" function?
|
||
/// Facilitates connecting to a card reader | ||
/// | ||
final class CardReaderConnectionController { | ||
public class CardReaderConnectionController { | ||
public enum UIState { |
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 state machine here is looking great, I'd say ultimately since this is in Yosemite it shouldn't reference the UI in any manner, but some sort of CardReaderConnectionState
instead. Then when we switch over the different cases in WooCommerce
via connectionUIStateSubscription = controller.$cardReaderState
is where we perform the specific calls to the alerts presenter which handles the UI bit
Thanks a lot for the feedback Gabriel, I agree with the suggestions and there is still a bunch of testing to be done. Though given the recent direction from leadership to not make significant changes that can affect the existing app, this PR seems unlikely to have a green light. I'm closing this PR for now but it'd be great to separate the UI logic if we have a chance in the future. |
Closes: #
Description
Testing instructions
Screenshots
RELEASE-NOTES.txt
if necessary.