Great Review many advanced concepts when organizing a SwiftUI project and general best practices with coding in SwiftUI. Very helpful would love to see more advanced topics and best practices videos. Maybe some on data storage/image loading and storage with large API responses. Big thank you and great videos!!!
On 16:24, the reason why `dismiss` wasn't used is mostly due to the view not needing to know presentation details. If we were to think in UIKit terms, in this case, we would send a message to the presenting viewController, who would then decide what needs to happen on a `dismissAction`. It could either be a dismiss, forwarding an event to analytics, etc. The benefits of this approach are that the view stays dumb, it's functionality can be modified without needing to modify the view itself.
Interesting point. But also by using dismiss, the view stays dumb. Dismiss would work if I use any standard presentation, like sheet, fullscreencover or navigationlink.
@@SwiftyPlace Hmm, let's say we have a new requirement where if the user taps on dismiss and if there's any meeting info, we want to display an alert prompting the user about their decision to cancel. Let's also say that this view when it's presented from some other place, it does not need to present an alert when tapping on dismiss. Now you have two requirements for the same view, if we were to go with the `dismiss` approach, we need to add some logic inside the button to either call dismiss or present an alert. The view also needs to know somehow which experience to show. You can imagine in such a case that leaving all of these decisions one layer above makes the view much more reusable.
Great Review many advanced concepts when organizing a SwiftUI project and general best practices with coding in SwiftUI. Very helpful would love to see more advanced topics and best practices videos. Maybe some on data storage/image loading and storage with large API responses. Big thank you and great videos!!!
Great stuff Karin, love these
thanks so much for this video!! i'd love to see you take a medium sized, non-organized app and organize it into MVVM.
More like this, please!
On 16:24, the reason why `dismiss` wasn't used is mostly due to the view not needing to know presentation details. If we were to think in UIKit terms, in this case, we would send a message to the presenting viewController, who would then decide what needs to happen on a `dismissAction`. It could either be a dismiss, forwarding an event to analytics, etc.
The benefits of this approach are that the view stays dumb, it's functionality can be modified without needing to modify the view itself.
Interesting point. But also by using dismiss, the view stays dumb. Dismiss would work if I use any standard presentation, like sheet, fullscreencover or navigationlink.
@@SwiftyPlace Hmm, let's say we have a new requirement where if the user taps on dismiss and if there's any meeting info, we want to display an alert prompting the user about their decision to cancel. Let's also say that this view when it's presented from some other place, it does not need to present an alert when tapping on dismiss.
Now you have two requirements for the same view, if we were to go with the `dismiss` approach, we need to add some logic inside the button to either call dismiss or present an alert. The view also needs to know somehow which experience to show.
You can imagine in such a case that leaving all of these decisions one layer above makes the view much more reusable.
Super helpful video. Keep up the good work :D
many thanks for many insights.
✨
Your accent sounds German with a tiny bit of French. Are you from the region of Germany near France?
write business logic right in ui presentation is "very professional"