How to correctly initialize a view model in SwiftUI: https://chris.eidhof.nl/post/swiftui-view-model/ (for when the view needs ownership of the view model).
SwiftUI View Model Ownership — Chris Eidhof

@chris The way I've been handling it (in small hobby apps, take with grain of salt) is to *always* put view models in the environment. In line with your article's advice, this has the advantage that it ensures state is updated in a body function.

Relevant to a discussion I was having with @orj recently, SwiftUI thrives on very few view models so using the environment makes sense (better drives a deep tree of views or passing through utility layout views).

@cocoawithlove @orj yeah, tbh, I don't use view models. The reason I wrote is is that this specific question in this form (the view should own it) comes up so often that I figured it'd be nice to have something to link to.
@chris What approach do you use instead of view models, typically?
@thehonkingsmith mostly plain structs in regular or state properties. I don't really build real apps 😅
@cocoawithlove @chris @orj Interesting approach. How would that work with multiple rooms in the same view hierarchy? Like in a list?
@mamouneyya @cocoawithlove @orj I think it'd work well?
@chris @cocoawithlove @orj Well, the type is used as a key which means you cannot have more than one in the same hierarchy, right? I guess that’s fine if the parent of that view passed the view model only for that subtree, but then I question the point of using the Environment at all.

@mamouneyya @chris @orj Environment values are not globals. The environment is a scoped context – so it exists only in the subtree where you apply it.

This means you can apply a separate environment value for every row in a list, and they will not interfere with each other.

@cocoawithlove @chris @orj Yeah, I know, but that means that you have to pass the single view model in the subtree of each cell, which makes me not see the value of using the Environment in this case (say, as opposed to passing the view model directly to the constructor as an @ ObservedObject). Or maybe it makes the “ownership” easier as you don’t have to worry about it? Usually when I think about the Environment, I am always too focused on the “propagation” aspect.
@mamouneyya @cocoawithlove @orj I’m not sure either. I guess one reason is if a bunch of subviews need that same VM?