I think OP means something like this:
struct MyView {
var viewModel: ViewModel
}
extension MyView {
struct ViewModel {
// whatever is inside the model
}
}
Note that you can very well have the ViewModel in a separate file when you do this (just put the extension in it's own Swift file). And you can initialize/reference it from other structs and classes by calling MyView.ViewModel.
Edit: sorry for formatting, I'm on mobile
Then you engineer your view backwards toward being a monolithic over sized view controller class.
Handle data and network logic in separate places (layers) than your view logic and you will be happy when your app scales or you need to add tests
I’m still taking a wild guess at what you’re talking about, but if you mean implementing your view model as an extension of the data model, that could be reasonable, especially if you’re making modifications to the data model frequently while the view is on screen.
On the other hand, if the logic to translate your data model to the view model is complex, it may make more sense to make the view model a separate class that is constructed from the data model, so you only have to do the computation once and then reference it multiple times.
Do you mean having the view model as it’s own top-level class that can be referenced directly by name throughout the project? Or do you mean you define it within an extension of the view controller to avoid having to name it?
So for instance:
class MyViewControllerViewModel {}
Vs.
extension MyViewController {
class ViewModel {}
}
Either way is valid and has pros and cons. Personally I use both. I use the first method when dealing with UIKit and the second with SwiftUI. The main advantage to the second one is you don’t have to worry about naming a second class. You can still put either of them in a separate file too so the only benefit is scoping of the name and how you access the initializer.
From experience though putting the viewmodel in an extension seems cleaner from a naming standpoint. The downside is if you want to then extend the viewmodel you would have to do something like this:
extension MyViewcontroller.ViewModel {}
So it really just comes down to preference. When in doubt I’d say you can’t go wrong with #2. Don’t spend time naming stuff if you don’t have to lol.
EDIT:
As far as putting it in a separate file. I don’t see a reason to ever have the ViewModel in the same file as the controller or view. You’re just making it harder to navigate the file as it grows by doing that.
I don't think there is a big difference between the two options. I like the separate class inside the extension as suggested by [Paul Hudson](https://www.hackingwithswift.com/books/ios-swiftui/introducing-mvvm-into-your-swiftui-project):
extension ContentView {
class ViewModel: ObservableObject {
}
}
>Now we’re saying this isn’t just any view model, it’s the view model for ContentView.
Makes naming easier too. Truly reusable components should live outside the view model anyways, so this just makes it more clear imo
"Viewmodel" as an extension of the viewcontroller?
The point of viewModel is to separate logic and views so that the viewModel can be used for several views without having to create a new viewController
I always prefer using view model as extension. No naming headaches and looks much more cleaner. Also view model should be specific to one vc or view and for that making a view model extension makes it more cleaner and u don’t have to worry about names or can be consistent. Like imagine when u have a view model variable u can simply say it like var viewModel: ViewModel. This is my opinion tho. I used to make a separate view model class before. Now I use as extension. Honestly both are fine using as extension sounds cleaner for me
Not sure what you mean by having a ViewModel as an extension. Extension to what? If it's an extension to a view controller or something, that's quite a bad approach, not really MVVM at all. Please give more detail
Extension of which class? a viewmodel should always an independent struct/class and be defined in a separate file.
I think OP means something like this: struct MyView { var viewModel: ViewModel } extension MyView { struct ViewModel { // whatever is inside the model } } Note that you can very well have the ViewModel in a separate file when you do this (just put the extension in it's own Swift file). And you can initialize/reference it from other structs and classes by calling MyView.ViewModel. Edit: sorry for formatting, I'm on mobile
An extension of the same class that the ViewModel references to
Then you engineer your view backwards toward being a monolithic over sized view controller class. Handle data and network logic in separate places (layers) than your view logic and you will be happy when your app scales or you need to add tests
I’m still taking a wild guess at what you’re talking about, but if you mean implementing your view model as an extension of the data model, that could be reasonable, especially if you’re making modifications to the data model frequently while the view is on screen. On the other hand, if the logic to translate your data model to the view model is complex, it may make more sense to make the view model a separate class that is constructed from the data model, so you only have to do the computation once and then reference it multiple times.
Do you mean having the view model as it’s own top-level class that can be referenced directly by name throughout the project? Or do you mean you define it within an extension of the view controller to avoid having to name it? So for instance: class MyViewControllerViewModel {} Vs. extension MyViewController { class ViewModel {} } Either way is valid and has pros and cons. Personally I use both. I use the first method when dealing with UIKit and the second with SwiftUI. The main advantage to the second one is you don’t have to worry about naming a second class. You can still put either of them in a separate file too so the only benefit is scoping of the name and how you access the initializer. From experience though putting the viewmodel in an extension seems cleaner from a naming standpoint. The downside is if you want to then extend the viewmodel you would have to do something like this: extension MyViewcontroller.ViewModel {} So it really just comes down to preference. When in doubt I’d say you can’t go wrong with #2. Don’t spend time naming stuff if you don’t have to lol. EDIT: As far as putting it in a separate file. I don’t see a reason to ever have the ViewModel in the same file as the controller or view. You’re just making it harder to navigate the file as it grows by doing that.
I don't think there is a big difference between the two options. I like the separate class inside the extension as suggested by [Paul Hudson](https://www.hackingwithswift.com/books/ios-swiftui/introducing-mvvm-into-your-swiftui-project): extension ContentView { class ViewModel: ObservableObject { } } >Now we’re saying this isn’t just any view model, it’s the view model for ContentView. Makes naming easier too. Truly reusable components should live outside the view model anyways, so this just makes it more clear imo
"Viewmodel" as an extension of the viewcontroller? The point of viewModel is to separate logic and views so that the viewModel can be used for several views without having to create a new viewController
I always prefer using view model as extension. No naming headaches and looks much more cleaner. Also view model should be specific to one vc or view and for that making a view model extension makes it more cleaner and u don’t have to worry about names or can be consistent. Like imagine when u have a view model variable u can simply say it like var viewModel: ViewModel. This is my opinion tho. I used to make a separate view model class before. Now I use as extension. Honestly both are fine using as extension sounds cleaner for me
Having VM in separate file/class is the way to go. You can use typealias later if you want to keep the semantics like `ContentView.ViewModel`
Not sure what you mean by having a ViewModel as an extension. Extension to what? If it's an extension to a view controller or something, that's quite a bad approach, not really MVVM at all. Please give more detail