Not really. I also touch on some important points about view models. Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇 ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
Thanks for your videos. There is a big But here. If you define a Controller (ViewModel) as an Environment object, it will always exist in memory. while when you are creating views and mentioning a ViewModel as @StateObject (you add @State, which is wrong for defining a ViewModel or controllers), it will be deinitialized when the view is destroyed. So for enterprise projects, it is a very bad way to create Controllers(ViewModels) as an environment object.
I am using Xcode 15 therefore @StateObject is now @State I recommend using a controller only when you want to share resources between views. It's the cleanest way of doing it. If the data is tied to a view I suggest ( not using a view model) using @State on the view only. Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇 ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
I think the only difference is not making it fileprivate strictly bounded to the view, but available everywhere. I do not see any other difference apart from the use of the Environment. Nevertheless I think that in more complex cases is necessary that a View has its specific ViewModel.
@@MaccabeeCaptainActually I did not understand either what’s the real big deal with this. It looks to me that this is not even a general architectural pattern like MVVM. But it may just be because I am not such a super expert…
View models should be used on views only. If you need to share data between views use a Controller. Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇 ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
Sorry, I don't really understand your question. Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇 ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
Hi, like you explanation, sure you are going to receive a lot of comments regarding the importance of MVVM because for large projects, and stuff like that. At the end I really support your comments regarding that no problem in put Business logic in the View, because at the end the MMVM file it has to be related to the view so not difference. You approach to use MVC is great.
Couldn't have said it better myself. The cleaner the architecture, the better. MVVM adds too much cluttter. Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇 ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
While some views can get away without the controller, there will be at leas one controller in your app, therefor MVC it is :) Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇 ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
In most complex cases it is. Next watch SwiftUI Navigation Made Easy: Harnessing the Magic of Enums 👇 ruclips.net/video/do4uZBXP6bc/видео.html&ab_channel=Rebeloper-RebelDeveloper
Stop using Spacer in SwiftUI (and what to use instead) 👉 ruclips.net/video/S6bufNjIteQ/видео.html&ab_channel=Rebeloper-RebelDeveloper
Thanks for the video. However, you only renamed VM to Controller and moved it in root view. The only point of this video was only a renaming!
Not really. I also touch on some important points about view models.
Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇
ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
@@rebeloper Don't get it. What has night mode got to do with MVVM vs MV+C
Thanks for your videos. There is a big But here. If you define a Controller (ViewModel) as an Environment object, it will always exist in memory. while when you are creating views and mentioning a ViewModel as @StateObject (you add @State, which is wrong for defining a ViewModel or controllers), it will be deinitialized when the view is destroyed. So for enterprise projects, it is a very bad way to create Controllers(ViewModels) as an environment object.
Apple deprecated @StateObject
@@Andrew-7324 Take a look at apple documentation for @StateObject, and also used cases and samples. It is not deprecated.
I am using Xcode 15 therefore @StateObject is now @State
I recommend using a controller only when you want to share resources between views. It's the cleanest way of doing it. If the data is tied to a view I suggest ( not using a view model) using @State on the view only.
Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇
ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
@@rebeloper Apple documentation:
If you need to store a reference type, like an instance of a class, use a StateObject instead.
@@sajjadsarkoobi @StateObject has been replaced by @State now
so if UserController was renamed UserViewModel how is that any different than MVVM?
I think the only difference is not making it fileprivate strictly bounded to the view, but available everywhere. I do not see any other difference apart from the use of the Environment. Nevertheless I think that in more complex cases is necessary that a View has its specific ViewModel.
@@yourbestsail just find it a bit amusing considering the clickbait title I guess..
@@MaccabeeCaptainActually I did not understand either what’s the real big deal with this. It looks to me that this is not even a general architectural pattern like MVVM. But it may just be because I am not such a super expert…
View models should be used on views only. If you need to share data between views use a Controller.
Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇
ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
Yes, in complex cases.
I think people are already using mvc like when passing data through screens we initialise in the main file and pass it as environment .
Agreed.
Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇
ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
Correct me if I'm wrong, but it's an easier way to Composition Root?
I do it in UIKit creating factories in the AppDelegate, it's the same effect?
Sorry, I don't really understand your question.
Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇
ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
Hi, like you explanation, sure you are going to receive a lot of comments regarding the importance of MVVM because for large projects, and stuff like that. At the end I really support your comments regarding that no problem in put Business logic in the View, because at the end the MMVM file it has to be related to the view so not difference. You approach to use MVC is great.
Couldn't have said it better myself. The cleaner the architecture, the better. MVVM adds too much cluttter.
Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇
ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
I totally disagree
Why is that? Can you explain?
It's MV architecture. NOT MVC!
While some views can get away without the controller, there will be at leas one controller in your app, therefor MVC it is :)
Next watch Mastering SwiftUI's Night Mode: Unlock Next-Level App Design 👇
ruclips.net/video/Qm1Sf0oOwfI/видео.html&ab_channel=Rebeloper-RebelDeveloper
MVVM is garbage
In most complex cases it is. Next watch SwiftUI Navigation Made Easy: Harnessing the Magic of Enums 👇
ruclips.net/video/do4uZBXP6bc/видео.html&ab_channel=Rebeloper-RebelDeveloper