In swiftUI TextField ,can we have some property similar to textfield.text in case of UIkit's TextField so that we do not have to explicitly mantain a State var to hold textfield value?

Question

Created Jun ’23

Replies 1

Boosts 1

Participants 2

I am newly shifting to SwiftUI from UIkit , and in UIkit if we have to use a TextField then we could use a delegate method shouldChangeCharacterIn(textfield:UITextField) and access text from textffield.text, for accessing text value of textfield .But in SwiftUI's TextField we have to pass a State variable for accessing value .

And in my app , i will have a lot of TextField and i dont want to mantain this much state variables .

Is there any way i can get UIkit like behavior in SwiftUI's Textfield ?

And also in case of button action ,we can use a func (sender:UIButton) in case of UIkit but in case of SwiftUI we did not get a object of sender ,Is there any way i can achive similar thing in SwiftUI func ?

Boost

Answer 1

CryptoKoa OP

Jun ’23

I transitioned from UIKit based coding to SwiftUI coding 2 years ago. SwiftUI is a completely different mindset, and it can be awkward to get SwiftUI to do UIKit kinds of things. With respect to TextField delegate methods and SwiftUI state variables - one way of thinking about it that worked for me was to gather together all of the data that you need to paint your view, and put that into either State variables or a data object. Example, instead of allowing the name, address, city and state TextFields to hold the data, it's better to define an Address struct that has those same data fields. Then, your SwiftUI app just paints the values that are in the Address struct.

Here's something else that really helped me make the transition: in UIKit programming, we tend to think of a TextField as having its own behaviors - like it holds the data for the name or address, and when the user types in that field, then the Textfield is responsible for updating it's value. In addition, it may be responsible for communicating that change to other objects in your app. In contrast, in SwiftUI, it's easiest to think about how the SwiftUI system throws away and re-creates any views whose data is no longer supporting the way the view is being painted. The data changes, then the View is discarded and re-created.

My suggestion would be to watch WWDC23's "Build an app with SwiftData" and just notice how different it is from UIKit. SwiftUI has evolved tremendously over the past 3 years, and it's now awesome expressive - but in it's own, unique way.

1