Closed lionel-alves closed 2 years ago
Probably not as elegant as what you're proposing in #15, but if your Screen
type conforms to Equatable
, you can also observe changes to the coordinator @State
via an onChange(of:perform:)
modifier.
For example:
struct Coordinator: View {
@State var routes: Routes<Screen> = [.root(.home)]
var body: some View {
Router($routes) { screen, _ in
switch screen {
case .home:
HomeView(onComplete: { routes.presentSheet(.second) })
case .second:
SecondView(onComplete: { routes.presentSheet(.third) })
case .third:
ThirdView(onComplete: { ... })
}
}
.onChange(of: routes) { [routes] newValue in
print(routes) // old value
print(newValue) // new value
// compare the two values above to check whether a sheet got dismissed")
}
}
}
Thanks Federico, that's a good workaround, we know everything from the routes @State
changes indeed. Not as convenient as having a onDismiss
but it works.
Router(...)
.onChange(of: routes) { [oldRoutes = routes] newRoutes in
let dismissedRoutes = oldRoutes.suffix(from: min(oldRoutes.endIndex, newRoutes.endIndex))
print(dismissedRoutes)
}
Hi, first of all thanks for making SwiftUI navigation easier with you library, it is the best approach I came across by far. As a big fan of coordinators, I think your approach is even better that with UIKit since it easy to have one coordinator for a small flow that can both push and present, very convenient!
My issue: Presenting sheets, there is no way to know when it is dismissed (the
onDismiss
on the native call is passed tonil
in you library). Exposing that would be very convenient as theonAppear
is not called for sheets (well known problem).Best regards