Very important point of summoning ViewModel in a test case was covered in this video. How am I supposed to test ViewModel, if it its a part/extension of View ? Developers should start reasoning about what they learn from internet. Also, every piece of software we write, needs to be tested. So, those who do not think of testing, will never think about such tight coupling between Views and ViewModels. That can work for someone's hobby projects. But while writing enterprise apps, such approach is simple going to be discarded.
People nowadays look for a Great Place to Work Certified organization, instead they should look for an organization to work with Great People. That reminds me of you Ravi.. Great work as always, I am not able to follow all your videos, but whenever I see your Videos, I feel great and happy! I recommend you to cover "Power of Process" in your upcoming videos (if possible) All my best wishes with you!
Indeed, it’s always good people who drive the process with their right mindset than taking things casually. Thank you for considering me as one of those person, and it means a lot coming from you Sir. I’ll try my best to do better. It’s always a pleasure reading comments from you, and I’ll cover the Power of Process in my coming videos soon.
Hi Ravi, I very well understand your explanation. Thanks for your videos! FYI we can access a private variable in the test case to set them `private (set)` you can check at 9:30. Just for idea but you are write model should be independent bot encapsulated within view.
Note: For creating the viewModel class inside the view extension, In the test cases, you could directly access the viewModel without creating the instance of the ContentView but still we would have the same problem, the VM are not independently testable and reusable. I would leave that choice to the developer to how they want to write tests for their application but mostly if a component is being tested you should be able to directly access that component without having to go through some other component.
Do you have the link to the Apple Dev's response @4:53 ? The link that appears there is somewhat misleading since it doesn't contain that actual response and seems to have been picked from somewhere else.
Does using @FetchRequest in views is a bad practice too. In the repository pattern video you mentioned that the view shouldn't have the idea of using CoreData. I tried using your idea of creating two data models one for coredata and one which gets fetched from internet sent to views etc. Exposed this proxy model and used @Published property to observe for changes. But the problem with this is loss of efficiency. Coredata objects are fetched in a fault state and thus requires very less memory. On the other hand create struct objects will mean every property gets loaded in the ram. Very confused about creating an offline app in swiftui that can fetch objects from internet and serialise them into persistence layer. Any help will be appreciated.
What’s the difference between the property wrappers @FetchRequest vs FetchRequest coz both will do the same thing for you so how do you loose efficiency?
@@CodeCat15 The published array is of Network Fetched Model which is struct and not a NSManagedObject. When you use @FetchRequest or FetchRequest it gives you CoreData entities. These are efficient because of the data fault state as i mentioned earlier. When i convert these entities to the structs i mentioned earlier to expose as a @Published array every piece of data will be loaded into RAM.
if i use @FetchRequest in views i need to work with coredata entity models directly which causes various issues if passed in a different thread than the context with which object was created. We will need to use perform/performAndWait to get these objects which ties the whole code with Coredata logic strongly
I forgot to mention that in the video so I added a note as comment for this specific code, yes you could do that but the point is you’ll still have tight coupling between view and the VM and if you want to pass that VM in some child view you can’t
Very important point of summoning ViewModel in a test case was covered in this video.
How am I supposed to test ViewModel, if it its a part/extension of View ? Developers should
start reasoning about what they learn from internet. Also, every piece of software we write,
needs to be tested. So, those who do not think of testing, will never think about such tight
coupling between Views and ViewModels. That can work for someone's hobby projects.
But while writing enterprise apps, such approach is simple going to be discarded.
People nowadays look for a Great Place to Work Certified organization, instead they should look for an organization to work with Great People. That reminds me of you Ravi.. Great work as always, I am not able to follow all your videos, but whenever I see your Videos, I feel great and happy!
I recommend you to cover "Power of Process" in your upcoming videos (if possible)
All my best wishes with you!
Indeed, it’s always good people who drive the process with their right mindset than taking things casually.
Thank you for considering me as one of those person, and it means a lot coming from you Sir. I’ll try my best to do better.
It’s always a pleasure reading comments from you, and I’ll cover the Power of Process in my coming videos soon.
Hi Ravi,
I very well understand your explanation. Thanks for your videos!
FYI we can access a private variable in the test case to set them `private (set)` you can check at 9:30. Just for idea but you are write model should be independent bot encapsulated within view.
yes that I missed while recording the session, thank you for letting me know about it.
Nice ravi
always happy your comment creative developers...😄😄
Glad the video was helpful Yogesh 😊
Thanks for clearing up the bad coding practices that are found on the internet. 😊
Glad it was helpful 😊
Note: For creating the viewModel class inside the view extension, In the test cases, you could directly access the viewModel without creating the instance of the ContentView but still we would have the same problem, the VM are not independently testable and reusable. I would leave that choice to the developer to how they want to write tests for their application but mostly if a component is being tested you should be able to directly access that component without having to go through some other component.
Do you have the link to the Apple Dev's response @4:53 ? The link that appears there is somewhat misleading since it doesn't contain that actual response and seems to have been picked from somewhere else.
Does using @FetchRequest in views is a bad practice too. In the repository pattern video you mentioned that the view shouldn't have the idea of using CoreData. I tried using your idea of creating two data models one for coredata and one which gets fetched from internet sent to views etc. Exposed this proxy model and used @Published property to observe for changes. But the problem with this is loss of efficiency. Coredata objects are fetched in a fault state and thus requires very less memory. On the other hand create struct objects will mean every property gets loaded in the ram. Very confused about creating an offline app in swiftui that can fetch objects from internet and serialise them into persistence layer. Any help will be appreciated.
What’s the difference between the property wrappers @FetchRequest vs FetchRequest coz both will do the same thing for you so how do you loose efficiency?
@@CodeCat15 The published array is of Network Fetched Model which is struct and not a NSManagedObject. When you use @FetchRequest or FetchRequest it gives you CoreData entities. These are efficient because of the data fault state as i mentioned earlier. When i convert these entities to the structs i mentioned earlier to expose as a @Published array every piece of data will be loaded into RAM.
if i use @FetchRequest in views i need to work with coredata entity models directly which causes various issues if passed in a different thread than the context with which object was created. We will need to use perform/performAndWait to get these objects which ties the whole code with Coredata logic strongly
Beautifully explained :)
Thanks a lot 😊
Very well explained 👌👍
Glad it was helpful, do share the video with your iOS group and feel free to ask questions.
Nice video Ravi. 👍
Glad it was helpful, do share the video with your iOS group and feel free to ask questions.
Loved it sir😊😊
Thank you Taj 👍
Good to see
Good to know about the misleading practices before than later
Why not. let obj = ContentView.ProductViewModel() ??
I forgot to mention that in the video so I added a note as comment for this specific code,
yes you could do that but the point is you’ll still have tight coupling between view and the VM and if you want to pass that VM in some child view you can’t
@@CodeCat15 Agree on this
Nice Ravi
Thank you Yogesh 😊