[Question] - Navigation State

[thebarndog]

Is there a recommended strategy for dealing with navigation state in TCA? The problem I'm encountering is I want to be able to serialize a list of actions that are dispatched to the store with their timestamps and then later, playback those actions on the store and watch how the application responds, essentially Redux DevTools for TCA.

The problem is that some rather consequential actions can happen outside of TCA that result in a major application state change. One of the classic examples is pushing a navigation view onto the stack. In SwiftUI, if I have a NavigationLink and that becomes active, no action is triggered on the store to show the next page but the transition occurs anyway and then the store and what's actually happening are out of sync.

I'm not sure what the best way to handle this problem is because it seems like it would almost be a library feature, like a Link SwiftUI view that TCA provides that dispatches a NavigationAction or something along those lines.

[dmeehan1968]

Can you not achieve this with NavigationLinks 'isActive' binding, using a viewStore.binding where the setter sends an identifier for the active link to the store?

[thebarndog]

You could but thats a pretty clunky api, it could benefit from a formalized way to do that.

[dmeehan1968]

the viewStore.binding API? Can you give an example of what's currently available and how it might be improved?

[thebarndog]

I'm just not a fan of the binding API in SwiftUI overall, it's not fantastic.

[lukeredpath]

You’re going to have a hard time trying to use SwiftUI without bindings, it’s one of its most fundamental building blocks. What do you dislike about it? I find it’s a fairly elegant encapsulation of two-way communication and composes well.

The solution to your problem here is to not use the NavigationLink API that doesn’t take a binding, it’s useless for all but the most basic of apps. You want your navigation to be state-driven which means modelling your navigation state in the store and using view store bindings.

TCA does need more tools to handle navigation for sure and I think there’s some work in progress on this (take a look at the nav branch). Have you watched the latest Pointfree navigation series? If not I’d highly recommend it. It doesn’t cover TCA but gives a solid foundation to SwiftUI navigation and has some good ideas about how to model navigation state and make use of bindings.

[thebarndog]

I dont love it because it's not clear from the name that its a two way binding. One object can be bound to another but not vice versa (like the Combine operator assign which binds data one way) or two objects can bound together, creating a bi-directional connection. It's a small thing but I just dont think the name of the property wrapper is quite right or descriptive enough. I would for example, name the view store api sync, not binding.

[thebarndog]

Going to close this, I think the original question of how to incorporate navigation state into an application has been answered.

[thebarndog]

I wanted to come back to this because I believe I found a spot where viewStore.binding falls down that I uncovered in an app I'm building.

Let's say I'm building a 1Password esque app and I have a screen where I want the user to input their master password. When they hit the button, I dispatch some action that turns a boolean on in my state called passwordSaved. That boolean then indicates that the navigation link should be active.

The problem is, because hitting the button already set the state appropriately, I just need the navigation link to react to that boolean and not send a value. However there's no variant of viewStore.binding that lets me do that.

Here's a code example:

  NavigationLink("", isActive: viewStore.binding(get: { $0.savedPassword }, send: { value in 
      if value {
          return .finishAndProceed
      } else {
           return .unwind
      }
  )) {
      MultifactorAuthenticationSetupFlow(store: store)
  }
      .hidden()

What happens is that I end up at the least, adding an additional action thats not needed, in this case finishAndProceed. It's redundant because that state can be derived from setting the password and a side effect can be added when the password gets saved to advance to the next page.

@stephencelis @dmeehan1968 does that make sense? I think it'd be very useful to have viewStore.binding(get:send:) where the action returned can be nil. The navigation state is already derived and resolved; there's no need to then dispatch a secondary action except where the binding is getting set to false. That's what I was trying to express above, that this ViewStore api can actually incur some boilerplate by not allowing for a no-op binding thats get only or at least, one that allows for nil to be returned.

[iampatbrown]

@thebarndog I'd normally opt for an action that takes a Bool and handling the different cases inside the reducer. eg:

let reducer = Reducer<State, Action, Void> { state, action, _ in
  switch action {
  case .navigationButtonTapped:
    return Effect(value: .setNavigation(isActive: true))

  case .setNavigation(true):
    state.isActive = true
    return .none

  case .setNavigation(false):
    state.isActive = false
    return .none
  }
}

You could also manage this at a binding level, though it's probably better to keep the logic inside the reducer.

Here are some examples:

Condition with binding + constant

struct ContentView: View {
  @State var isActive = false

  var body: some View {
    VStack {
      Button("Go to Page 2") { self.isActive = true }

      NavigationLink("", isActive: self.isActive ? self.$isActive : .constant(false)) {
        Text("Page 2")
      }.hidden()
    }
  }
}

Filter helper on binding:

extension Binding {
  func filter(_ isIncluded: @escaping (Value) -> Bool) -> Self {
    .init(
      get: { self.wrappedValue },
      set: { newValue, transaction in
        guard isIncluded(newValue) else { return }
        self.transaction(transaction).wrappedValue = newValue
      }
    )
  }
}

...
NavigationLink("", isActive: self.$isActive.filter(!)) {
  Text("Page 2")
}.hidden()
...

You could probably incorporate filter into a ViewStore extension to get the result you're after (not sure how safe this is):

extension ViewStore {
  public func binding<LocalState>(
    get: @escaping (State) -> LocalState,
    send localStateToViewAction: @escaping (LocalState) -> Action?
  ) -> Binding<LocalState> {
    self.binding(
      get: get,
      send: { localStateToViewAction($0)! }
    ).filter { localStateToViewAction($0) != nil }
  }
}

[thebarndog]

It still introduces an additional local action into my view which is what I'm trying to avoid in the first place