I am having a hard time wrapping my head around MVVM with SwiftUI.
Whenever I use it, things feel wrong and hack-y. Unlike with UIKit.
In MVVM + SwiftUI, who owns the state ? Is it the ViewModel ? And who owns the ViewModel, the @State container ?
And how do you control the life time of your ViewModels ?
Feels like I am probably missing some good ideas around why itâs popular (other than an intermediate phase when codebases are migrating from UIKit).
Any experienced programmer worth their salt will tell you that â˘producing⢠code â learning syntax, finding examples, combining them, adding behaviors, adding complexity â is the â˘easy⢠part of programming.
The hard part: âHow can it break? How will it surprise us? How will it change? Does it â˘really⢠accomplish our goal? What â˘is⢠our goal? Are we all even imagining the same goal? Do we understand each other? Will the next person to work on this understand it? Should we even build this?â
@jaredsinclair Great post! Small clarification on explicit view identity: the .id() modifier acts in *addition* to the structural identity defined by the viewâs position in the view hierarchy. So .id() can never make two non-identical views identical, only the other way around. These two views have different identity despite having the same .id():
if flag {
MyView().id("one")
} else {
MyView().id("one")
}
Be Careful When you Initialize a StateObject Property Wrapper â https://jaredsinclair.com/2024/03/14/state-object-autoclosure.html
Thereâs an easy pitfall to fall into, and it can totally undermine the reason you're using StateObject in the first place.
@nicklockwood @rhysmorgan Yeah itâs not the same, just similar.
But just wait until this proposal is accepted. They will become super powerful and I bet will be commonly used
https://forums.swift.org/t/pitch-inheriting-the-callers-actor-isolation/68391
Hi. One problem we've been seeing with Swift concurrency is that there isn't an easy way for async functions to polymorphically share their callers' actor isolation. This makes it hard to use certain kinds of async abstractions from isolated contexts because technically the async functions in the abstraction have a different isolation, which means e.g. you can't share non-Sendable values with them. It also can have unwanted performance consequences. I've written a proposal which adds a handf...