SwiftUI mechanism for Navigations can be weird for good old UIKit developers.

And for those who wants to make all their Views isolated, and make them not aware of any navigation context, it can be hard to achieve this with the current SwiftUI implementation.

So, that's my reflexions here :

A basic navigation is used like this :

struct CustomView: View {
  var body: some View {
    VStack {
      // ...View contents
      NavigationLink("MyNavigationButton") {
        MyDestinationView()
      }
      // ...View contents
    }
  }
}

That NavigationLink must be in the view that makes navigation. But what if we want to make our Custom view completely isolated from Navigation context ? For example, the navigation is triggered by some Button, but we don't want to do this directly via NavigationLink, because it can have multiple destinations, depending on app context.

So, swiftui-navigation is a good start for this. We can use pointfree's amazing tools as a start. Using the new inits with unwrapping / case parameters and a Route enum, we can easily drive the navigation.

But there's the last problem : Our view still knows about the NavigationLink.

Here's the solution : we can make a custom ViewModifier to wrap that binding-controlled NavigationLink in a new Custom view, which automatically embeds your CustomView, with the desired NavigationLink. As the NavigationLink view is an empty view, we can easily hides it with the modifier (see the implementation in PR).

So then, we can have something like this :

struct MyApp: App {
  var body: some View {
    CustomView()
      .navigate(when: $route, is: /Route.destination) { _ in
        MyDestination()
      }
  }
}

For a more complete example, look at the 10 CaseStudy included in the PR. This is a first draft for this feature. Sure it can be improved.

Describe the bug I am driving a detail screen with an Edit/Confirm logic. Entering the "edit" works as expected, but the Confirm- and the Cancel-button need to be tapped twice in order to end editing. The editing itself is bound to an optional string that is set when the Edit-button is tapped.

The view is driven off of an IfLet.

Please forgive me if this is something explained in one of your videos–as a subscriber of your content feel free to just point me to a related video if available :-)

To Reproduce This is a sample project mimicking the behaviour I see in my project.

import SwiftUI
import SwiftUINavigation

@main
struct so_IfLetIssueApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

struct ContentView: View {
    @State private var title = "Some fancy title"
    @State private var editingTitle: String?
    
    var body: some View {
        NavigationStack {
            Form {
                IfLet($editingTitle) { $editingTitle in
                    TextField("Title", text: $editingTitle)
                } else: {
                    Text(title)
                }
            }
            .toolbar {
                ToolbarItem(placement: .confirmationAction) {
                    Button(editingTitle == nil ? "Edit" : "Confirm") {
                        if let editingTitle {
                            title = editingTitle
                            self.editingTitle = nil
                        } else {
                            editingTitle = title
                        }
                    }
                }
                if editingTitle != nil {
                    ToolbarItem(placement: .cancellationAction) {
                        Button("Cancel") {
                            editingTitle = nil
                        }
                    }
                }
                ToolbarItem(placement: .bottomBar) {
                    Text("editingTitle is \"\(editingTitle == nil ? "nil" : editingTitle!)\"")
                }
            }
        }
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
    
}

Expected behavior Tapping the "Confirm" or the "Cancel" button once should end editing by setting the optional binding to nil.

Screencast

https://user-images.githubusercontent.com/91844195/202385876-bbebb8e8-f50c-4c07-9302-ca7d594b7f98.mp4

Environment

• swiftui-navigation version [e.g. 0.1.0]
• Xcode Version 14.1 (14B47b)
• Swift 5.5
• OS: macOS 12.6.1 (21G217)

Describe the bug onNavigate being called twice on tapping the default back button of NavigationLink

To Reproduce

struct ContentView: View {

    enum Route {
        case a
        case b
        case c
    }

    @State var route: Route?

    var body: some View {
        NavigationView {
            NavigationLink(
                unwrapping: $route,
                case: /Route.a,
                destination: { _ in Text("A detail") },
                onNavigate: {
                    route = $0 ? .a : nil }
            ) { Text("A row") }
        }
    }
}

Expected behavior onNavigate should be called only once when we tap on back button

Screenshots NA

Environment

• swiftui-navigation version: Main branch
• Xcode: 13.0
• Swift: 5.5
• OS: 11.6.1

Additional Comment

In PointFree demo project, if I comment this: .navigationBarBackButtonHidden(true), then this same issue can be reproduced in that demo project as well.

Describe the bug When running the Inventory example, the Add button sometime becomes unresponsive after the "Add" modal sheet is dismissed. Not sure when or what triggers it because it doesn't happen all the time.

To Reproduce Run the example, open the "Add" modal, save an item and tap "Add" again. Repeat.

Expected behavior The "Add" button to work all the time.

Environment

• swiftui-navigation version 0.1.0
• Xcode 13.1
• Swift 5.5
• OS: iOS 15 Simulator

The new ButtonState has an id with default UUID() value which breaks test in a TCA application. ("// Not equal but no difference detected:"). The custom equality check ignores the id

Describe the bug Updates to Binding.swift in #28 changed behavior in the way I'm using the case(_:) modifier to help drive navigation to nested routes in my iOS 15+ app.

It's possible I'm using this modifier based on incorrect expectations, but since this presents itself as a regression based on my current usage I'm using the bug template. Please let me know what additional information I can provide.

To Reproduce Run the contrived app below. Both buttons should present a sheet that indicates their selection. The sheet correctly displays using library version 0.3.x and never displays when using version 0.4.x

import SwiftUI
import SwiftUINavigation

@main
struct Application: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

struct ContentView: View {
    enum Route {
        case component(Component.Route)
    }

    @State var route: Route?

    var body: some View {
        VStack {
            Text("Hello user!")

            Component(route: $route.case(/Route.component))
        }
        .sheet(unwrapping: $route, case: /Route.component) { $route in
            Text("You selected \(route == .optionA ? "Option A" : "Option B")")
        }
    }
}

struct Component: View {
    enum Route {
        case optionA
        case optionB
    }

    @Binding var route: Route?

    var body: some View {
        VStack {
            Button("Option A") {
                route = .optionA
            }

            Button("Option B") {
                route = .optionB
            }
        }
    }
}

Expected behavior I'd expect this modifier to behave in v0.4.x as it did in v0.3.0, based on my understanding of the usage of that modifier.

Screenshots n/a

Environment

• swiftui-navigation version 0.3.0 v 0.4.4
• Xcode 14.1
• Swift 5.7
• OS: iOS 15+

Additional context n/a

This seems to fix #44. For some reason, it doesn't works with a wrapper view _Bind<ModelValue: _Bindable, ViewValue: _Bindable, Content: View>: View. I initially thought that the escaping closure of WithState was providing enough invalidation to make the changes effective, but it also works if one removes WithState (and the hasAppeared logic), so I don't really know what's happening here. Maybe the stored _Bindable are interfering with SwiftUI's diffing algorithm and are not properly observed/handled. This PR is mostly there to serve as a basis for discussion, as many things are still nebulous.

If I'm not mistaken, Identifiable is only used to simplify ForEach iteration in the actions.

This PR removes the uncontrolled Identifiable conformance for ButtonState and AlertState. The button's array is indexed before iterating over it, and theses indices are used as unique identifiers. Because of the nature of Alert and Confirmation dialog, this likely won't have unexpected side-effects. We could probably use enumerated() instead of zip here and I can update the PR if you want.

It also restores automatic Equatable and Hashable conformance for ButtonState. In my experience, using a partial Equatable conformance inevitably lead to incoherent situations and invariants being broken in the long run.

Please let me know if I'm missing something and Identifiable is used in other places than these loops.

Because this library makes it easy to add logic around navigation, it's probably also a good idea to ship with helpers that work around some surprising bugs/behaviors that currently exist in SwiftUI. For example, as noticed by #10, NavigationLink writes nil to its binding twice on dismissal.

It's probably not appropriate for us to automatically filter duplicate writes, but we can at least ship a Binding.removeDuplicates() that makes it easy to achieve this behavior.

Apple's online documentation says that the version of NavigationLink.init being uses is deprecated.

https://developer.apple.com/documentation/swiftui/navigationlink/init(destination:isactive:label:)

Thought it would be nice to have a case study showing how to deal with a list of navigation links. This is the simplest kind (i.e. each row has a route enum and we only pass binding to child view), but it's at least something. Maybe in the future we demonstrate a more complicated one like what is in the inventory case study.

Allowing Binding.case to always be writable may result in unwanted behaviour. If a binding changes case, it may be subsequently set to nil after the previous case is dismissed. Writing when the enum is nil or when the case matches could be a solution. I'm unsure if this is a common use case or if this change introduces some other unwanted behaviour. I just noticed a difference while replacing some customer helpers.

An example:

struct ContentView: View {
  @State var route: Route?

  enum Route { case foo, bar }

  var body: some View {
    VStack {
      Button("Show Foo") { self.route = .foo }
    }
    .confirmationDialog(
      title: { Text("Foo") },
      unwrapping: self.$route.case(/Route.foo),
      actions: { Button("Show Bar") { self.route = .bar } },
      message: { Text("Foo") }
    )
    .sheet(unwrapping: self.$route.case(/Route.bar)) { _ in
      Text("Bar")
    }
  }
}

Hello, I am trying to build the documentation of my app (Product -> Build Documentation). However, it fails to compile for the _SwiftUINavigationState target in this project. .

It looks like it is working for other TCA libraries, just this target in particular has this problem.

Let's say I want to initialize a ConfirmationDialogState object within a reducer like this:

state.confirmationDialog = .init(
  title: .init("Skip tutorial?"),
    buttons: [
      .destructive(
        .init("Yes, skip"), action: .send(.confirmDeletionButtonTapped, animation: .default)
        ),
      .cancel(.init("No, resume"), action: .send(.dismissDeletionPrompt))
    ]
)

In addition, I want to add accessibility labels (for example, I want to have a confirmation dialog display a timestamp but for VoiceOver users, I want it to not say 'zero colon 54'). I think the way to do this the SwiftUI way would be:

state.confirmationDialog = .init(
  title: .init("Skip tutorial?"),
    buttons: [
      .destructive(
        .init("Yes, skip").accessibilityLabel("HELLO WORLD"), action: .send(.confirmDeletionButtonTapped, animation: .default)
        ),
      .cancel(.init("No, resume").accessibilityLabel("HOWDY"), action: .send(.dismissDeletionPrompt))
    ]
)

Doing this however does not actually pass accessibility labels as I'd expect, and it might have to do with how the convenience initializers and helper functions setup the buttons. But I do see that TCA includes accessibility support in TextState.swift. Perhaps I'm missing how to properly use accessibility labels? Or is there an issue with how ConfirmationDialogState supports accessibility labels? I'd be happy to debug this myself and create a PR, but I want to make sure I'm not missing anything. Thanks!