-
Love the new SwiftUI Introspect Module. Great job. It indeed seems very stable and reliable. I had one question though about explicitly listing the versions that we want to cover with an introspection. Is this TextField example safe to do/ use in your opinion? @_spi(Internals) import SwiftUIIntrospect
import UIKit
extension iOSViewVersion<TextFieldType, UITextField> {
public static let v15AndAbove = Self(for: .v15AndAbove)
}
extension iOSVersion {
public static let v15AndAbove = iOSVersion {
if #available(iOS 15, *) {
return true
}
return false
}
} And then in an introspection: var body: some View {
content
.introspect(.textEditor, on: .iOS(.v15AndAbove)) { uiTextView in
uiTextView.inputView = keyboardType.keyboardInputView
}
} Because in my library I want to assure that I should I forget on updating the library code for new iOS releases, I want it to implicitly cover (potentially) newer versions already, without me needing to issue a new update. Or do you see an issue/risk in doing that? Example where i am trying to adapt CustomKeyboardKit to use the new API: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Hi @paescebu, glad to hear you're happy with the new module, and thank you for being an avid user :) In short: yes, it's completely fine to do. If the underlying UIKit view type changes in the future, the callback simply won't be called. I debated with myself quite a bit whether it makes sense to cover future platforms by default. But this comes with a few uncomfortable API quirks that ultimately make the library less intuitive and predictable. At the end of the day, I didn't want to sacrifice intuitiveness for the sake of ergonomics — which was arguably one of the biggest pitfalls of the original API—, and so this strictness is a trade-off I believe to be worthwhile for most users. For library developers such as yourself, I do encourage rolling out more lenient, custom version specifiers that encompass whatever scope you're after. At the end of the day, extensibility is one of this library's strongest suits to support advanced use cases just like the one you mentioned. I hope this helped. |
Beta Was this translation helpful? Give feedback.
Hi @paescebu, glad to hear you're happy with the new module, and thank you for being an avid user :)
In short: yes, it's completely fine to do. If the underlying UIKit view type changes in the future, the callback simply won't be called.
I debated with myself quite a bit whether it makes sense to cover future platforms by default. But this comes with a few uncomfortable API quirks that ultimately make the library less intuitive and predictable. At the end of the day, I didn't want to sacrifice intuitiveness for the sake of ergonomics — which was arguably one of the biggest pitfalls of the original API—, and so this strictness is a trade-off I believe to be worthwhile for most users.
For l…