-
Notifications
You must be signed in to change notification settings - Fork 51
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
USB connection type #188
USB connection type #188
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -37,6 +37,11 @@ export type ConnectBluetoothReaderParams = { | |
locationId?: string; | ||
}; | ||
|
||
export type ConnectUsbReaderParams = { | ||
reader: Reader.Type; | ||
locationId?: string; | ||
}; | ||
|
||
export type LineItem = { | ||
displayName: string; | ||
quantity: number; | ||
|
@@ -97,6 +102,13 @@ export type ConnectInternetResultType = | |
} | ||
| { reader?: undefined; error: StripeError }; | ||
|
||
export type ConnectUsbReaderResultType = | ||
| { | ||
reader: Reader.Type; | ||
error?: undefined; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hrm, I don't love this type, but I see it's already a pattern so we can just go with it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You'd expect the error type to be defined? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So for the JS SDK we return one or the other and the user is expected to refine
I'm not quite sure how TS handles this type of union as it looks like in the relevant code we're still checking if the reader is not null even if we don't have an error. Either way seems like we can be a bit more accurate here, I'll ticket to follow up as long as it's not a behavior we're forced into from android / ios. |
||
} | ||
| { reader?: undefined; error: StripeError }; | ||
|
||
export type DisconnectReaderResultType = { | ||
error: StripeError; | ||
}; | ||
|
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 wow, didn't expect this much code to be needed, is this because the android SDK doesn't surface these messages properly?
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.
Ah perhaps I misunderstood when we were talking earlier. Nope, this error handling logic is required because we're going from untyped JS to typed Kotlin. If we didn't have these checks we'd end up throwing null pointer exceptions when invalid input is received.