Hi! I really appreciated your example of pattern using the Coordinator, but I have some doubts regarding its use when various dependencies come into play: what happens when the views have some 'external' dependencies? In real world scenarios, it is likely that a page has multiple dependencies, some of them being some Services instances managing side effects and interacting with the external world (e.g. API calls), and not just pure data models like in your example (the Profile struct). How would you manage (the injection of) these dependencies in this case? For example, if the DetailView had 2 services (e.g. ItemsService and LocationService), which are specific to the DetailView and not directly used by the parent ContentView, you cannot create them inside the ContentView itself this time and inject them into a Page instance by the coordinator of course. - So would you inject them from the coordinator build() method? If yes, how? Would you store a reference of these services directly inside the Coordinator instance? - Or is it maybe better to avoid the 'build()' method, and just instantiate the views inside the .navigationDestination(), injecting there the 2 services (coming from the CoordinatorView)? Thank you very much in advance. I would love to use this pattern, but I have these concerns when coming to real complex projects
Welcome! BTW have you seen Firebase Login in SwiftUI: Step by Step Masterclass 👇 ruclips.net/video/9lRWau51lGw/видео.html&ab_channel=Rebeloper-RebelDeveloper
I've been trying to implement this in Xcode 15 beta with Observable macro on Coordinator class but it doesn't seem to be working. I reproduced your more robust Coordinator setup (different video) and am now trying to pass a Profile object (from CoordinatorView to Views in NavigationStack) that is stored with SwiftData. In essence, I want to implement this Coordinator pattern and leverage dependency injection with the latest tools from Apple. Not sure if the complications that I'm running into are surmountable.
Update: I've been subtracting complexity from my implementation while trying to preserve the Observable macro and ESB architecture (removed the passing of SwiftData for test Views). Still not working for me, however. The first View is shown as expected but subsequent navigations are unsuccessful.
Ok, I've replicated your implementation successfully with non-ESB pattern. My problem, then, boils down to trying to implement Coordinator pattern with ESB architecture.
For the Coordinator you doo need some sort of Environment. The Coordinator can live side by side the ESB pattern BTW have you seen Firebase Login in SwiftUI: Step by Step Masterclass 👇 ruclips.net/video/9lRWau51lGw/видео.html&ab_channel=Rebeloper-RebelDeveloper
😁 Have you seen my latest video? 👉 NavigationStack vs. NavigationCoordinator: You Won’t Believe the Difference! ruclips.net/video/7fb7CXty5i4/видео.html
With this approach you cannot :( BTW have you seen Firebase Login in SwiftUI: Step by Step Masterclass 👇 ruclips.net/video/9lRWau51lGw/видео.html&ab_channel=Rebeloper-RebelDeveloper
A workaround for this could be make the class or struct that you want to inject to conform Hashable. In my case i had to create UUID property inside my dependency and then extend my class to Hashable, on the first func i returned something like this: return lhs.uuid == rhs.uuid and on the second one i made something like this: func hash(into hasher: inout Hasher) { hasher.combine(uuid.uuidString) } hope it can help you or anyone want who needs it.
SwiftUI Navigation Perfected: Harnessing NStack's Game-changing Capabilities 👉 ruclips.net/video/nrtr14iOj0E/видео.html&ab_channel=Rebeloper-RebelDeveloper
finally this is should be primary example of using navigation stack
Have you seen my latest video? 👉 NavigationStack vs. NavigationCoordinator: You Won’t Believe the Difference!
ruclips.net/video/7fb7CXty5i4/видео.html
Hi!
I really appreciated your example of pattern using the Coordinator, but I have some doubts regarding its use when various dependencies come into play: what happens when the views have some 'external' dependencies?
In real world scenarios, it is likely that a page has multiple dependencies, some of them being some Services instances managing side effects and interacting with the external world (e.g. API calls), and not just pure data models like in your example (the Profile struct). How would you manage (the injection of) these dependencies in this case?
For example, if the DetailView had 2 services (e.g. ItemsService and LocationService), which are specific to the DetailView and not directly used by the parent ContentView, you cannot create them inside the ContentView itself this time and inject them into a Page instance by the coordinator of course.
- So would you inject them from the coordinator build() method? If yes, how? Would you store a reference of these services directly inside the Coordinator instance?
- Or is it maybe better to avoid the 'build()' method, and just instantiate the views inside the .navigationDestination(), injecting there the 2 services (coming from the CoordinatorView)?
Thank you very much in advance. I would love to use this pattern, but I have these concerns when coming to real complex projects
Thanks!
Welcome! BTW have you seen Firebase Login in SwiftUI: Step by Step Masterclass 👇
ruclips.net/video/9lRWau51lGw/видео.html&ab_channel=Rebeloper-RebelDeveloper
I've been trying to implement this in Xcode 15 beta with Observable macro on Coordinator class but it doesn't seem to be working. I reproduced your more robust Coordinator setup (different video) and am now trying to pass a Profile object (from CoordinatorView to Views in NavigationStack) that is stored with SwiftData. In essence, I want to implement this Coordinator pattern and leverage dependency injection with the latest tools from Apple. Not sure if the complications that I'm running into are surmountable.
Update: I've been subtracting complexity from my implementation while trying to preserve the Observable macro and ESB architecture (removed the passing of SwiftData for test Views). Still not working for me, however. The first View is shown as expected but subsequent navigations are unsuccessful.
Ok, I've replicated your implementation successfully with non-ESB pattern. My problem, then, boils down to trying to implement Coordinator pattern with ESB architecture.
For the Coordinator you doo need some sort of Environment. The Coordinator can live side by side the ESB pattern
BTW have you seen Firebase Login in SwiftUI: Step by Step Masterclass 👇
ruclips.net/video/9lRWau51lGw/видео.html&ab_channel=Rebeloper-RebelDeveloper
Matrix moment here 13:24 😂
😁
Have you seen my latest video? 👉 NavigationStack vs. NavigationCoordinator: You Won’t Believe the Difference!
ruclips.net/video/7fb7CXty5i4/видео.html
how can I pass non-hashable dependencies?
With this approach you cannot :(
BTW have you seen Firebase Login in SwiftUI: Step by Step Masterclass 👇
ruclips.net/video/9lRWau51lGw/видео.html&ab_channel=Rebeloper-RebelDeveloper
A workaround for this could be make the class or struct that you want to inject to conform Hashable.
In my case i had to create UUID property inside my dependency and then extend my class to Hashable, on the first func i returned something like this:
return lhs.uuid == rhs.uuid
and on the second one i made something like this:
func hash(into hasher: inout Hasher) {
hasher.combine(uuid.uuidString)
}
hope it can help you or anyone want who needs it.