@State
With SwiftUI, a number of new features have been added, including property wrappers.
The @State Property Wrapper is one of many. This wrapper allows us to change values inside a Struct that would normally not be possible since Structs are value types. The storage of a Property marked with @State is taken out of our Struct and stored in a Shared Storage managed by SwiftUI. Once a value of the properties changes, the current view is destroyed and a new one is generated. We use @State as a single source of truth, which means there is only one place that determines the value of our Property.
It can also be imagined like this: If we create a property that is marked with @State, we are not actually creating our own variable, but rather telling SwiftUI to create something in the background where our values are stored and monitored. So you could say that @State var is our delegate that gives us access to the wrapper. So every time our @State property gets a new value or the property is read, SwiftUI notices this because the values are monitored. With this information, it is then possible to reload any view that has a reference to the @State Properties.
This is not all that @State can do. We know:
- With @State you can change the properties in the Struct
- SwiftUI watches the status
- The view is reloaded after a @State property is changed
- SwiftUI generates two additional properties in the background
Wait, what? SwitUI generates two additional properties? Why is that so? There is an answer to this question and it is not that complicated. As an example, let’s create a @State property.
In the background, two more properties are created: $name and _name. So in the end we have three properties that we can use, each property having a different purpose.
- name is the actual property that also returns the string „Peter Parker“. It is equivalent to _name.wrappedValue. We use this type of property when we want to display it in the View.
- _name refers to the underlying storage of the Struct (Binding <String>).
- $ name is the projected value (projectedValue) and equivalent to _name.projectValue, which is also our binding at the same time (Binding <String>). This type of property we use to bind ourselves to something like a TextField („Name“, text: $ name). If the TextField changes, the state property name also changes and the View is reloaded
After this, you may still have a question. What is the exact difference between _ and $ now. The $ property is a get-only property, which means we can only get values. However, in order to set a value in a binding such as in an init(), we need to use the _ because it allows us to access the property wrapper as a whole.
This would also finish the topic of @State. A tip at the end: @State should always be marked private whenever possible. This is also recommended by Apple. The background is that no external source should be able to change our @State property and the property is only considered property of the actual view.
@State
Mit SwiftUI sind eine Reihe von neuen Features hinzugekommen. Darunter zählen auch die Property Wrappers.
Der @State Property Wrapper ist einer von vielen. Dieser Wrapper ermöglicht es uns Werte innerhalb eines Structs zu verändern, das normalerweise eigentlich nicht möglich ist, da Structs value types sind. Der Storage einer Propertie, die mit @State markiert sind, werden aus unserem Struct geführt und in einem Shared Storage abgelegt, der von SwiftUI gemanagt wird. Sobald sich ein Wert der Properties ändert, wird die aktuelle View zerstört und eine neue generiert. Wir benutzen @State als eine single source of truth, das bedeutet, dass es nur eine Stelle gibt, die den Wert, von unserer Propertie bestimmt.
Man kann sich das Ganze auch so vorstellen: Wenn wir eine Propertie erstellen, die mit @State markiert ist, erstellen wir damit nicht wirklich unsere eigene Variable, sondern sagen SwiftUI eher damit, dass sie etwas im Hintergrund erstellen soll, wo unsere Werte gespeichert und überwacht werden. Man kann also sagen, dass @State var unser Vermittler (Delegate) ist, der uns den Zugang zum Wrapper gibt. Also jedes Mal, wenn unsere @State Propertie einen neuen Wert bekommt oder die Propertie gelesen wird, bemerkt SwiftUI das, weil es die Werte überwacht werden. Mit dieser Information ist es dann möglich irgendeine View, die einer Referenz auf die @State Properties hat neu zu laden.
Das ist aber noch nicht alles, was @State kann. Wir wissen:
- Mit @State lassen sich die properties im Struct verändern
- SwiftUI überwacht den Status
- Die View wird nach Änderung einer @State Propertie neu geladen
- SwiftUI erzeugt im Hintergrund zwei weitere Properties
Warte was? SwitUI erzeugt zwei weitere Properties? Wieso ist das so? Auf diese Frage gibt es auch eine Antwort und die ist gar nicht mal so kompliziert. Als Beispiel erstellen wir uns eine @State Propertie.
Im Hintergrund werden dabei zwei weitere Properties angelegt. $name und _name. So haben wir am Ende drei Properties, die wir benutzen können, wobei jede Propertie einen anderen Zweck hat.
- name ist die Eigentliche Propertie, die uns auch den String “Peter Parker“ zurückgibt. Es ist äquivalent zu _name.wrappedValue. Wir benutzen diese Art von Propertie, wenn wir diese in der View anzeigen wollen
- _name bezieht sich auf den zugrunde liegenden Speicher des Structs (Binding<String>)
- $name ist der projizierte Wert (projectedValue) und äquivalent zu _name.projectValue, das auch gleichzeitig unser binding ist (Binding<String>). Diese Art von Propertie benutzen wir um uns an etwas zu binden wie z.B. einem TextField(“Name“,text: $name). Ändert sich das TextField ändert sich auch die state Propertie name und die View wird neu geladen.
Hiernach stellst du dir vielleicht noch eine Frage. Was ist jetzt der genaue Unterschied zwischen _ und $. Die $ Propertie ist eine get-only propertie, das bedeutet, dass wir nur Werte bekommen können. Um jedoch bei einem Binding einen Wert setzen zu können wie zum Beispiel in einer init() müssen wir den _ benutzen, weil wir somit auf den property wrapper als Ganzes zugreifen können.
Hiermit wäre das Thema zu @State auch schon abgehackt. Ein Tipp noch zum Schluss: @State sollte man möglichst immer als private markieren. Dies wird auch von Apple empfohlen. Der Hintergrund ist, dass keine externe Quelle unsere @State Propertie verändern darf und die Propertie auch nur als Eigentum der eigentlichen View angesehen wird.