Re-examine platform-specific AutoFill API #16
Labels
enhancement
New feature or request
Milestone
Comments
Firehed
added a commit
that referenced
this issue
Jul 28, 2024
As noted in #29, the initial design of the autofill interactions used a delegate-based system, rather than async/await like the modal APIs. This was based on an incorrect assumption (carried over from web, where it may also be flawed) on how promises resolve. Upon further experimentation, it seems perfectly fine and non-problematic to have a promise that might take minutes to resolve and not have it block other interactions. This (breaking) change adjusts the autofill API to also use async/await instead of delegates. Client code is a lot more straightforward, and the internals become more reliable since a bunch of conditional paths are eliminated. In the same vein, I've also added a new `.unsupportedOnPlatform` error code so that clients can have fewer availability checks, part of #30. The API as a whole is still `#if`'d to iOS+visionOS, but that will get lifted eventually in a separate PR (see #16).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the AutoFill API in the SDK is
#if-defined on the supporting platforms, which a) led to #15 and b) makes the SDK a bit more complex to use.I think it would be a better experience for developers to be able to always call the AF APIs in our SDK, and no-op the internals (or immediately return an error) on the platforms with no support.
The text was updated successfully, but these errors were encountered: