Navigation: Problem of understanding ViewStore Binding value

[REF2111]

Hello everyone!
Our team is thrilled by this new framework, because it seems to solve our problems for architecture in SwiftUI. Thank you for that in the first place! 👏

In the last days we did a deep dive and tried to analyse the TicTacToe app out of the examples, but we couldn't figure out the particular behaviour when tapping the "Log in" button with 2FA credentials entered:
https://github.com/pointfreeco/swift-composable-architecture/tree/main/Examples/TicTacToe

In the app, there is a (optional) navigation from the login screen to the 2FA-screen. We understood that the IfLetStore only gives us a view as destination if the twoFactor attribute of the LoginState is != nil. We also understood that the view is presented while the isActive bool is true which depends on the isTwoFactorActive attribute of the ViewState, which again depends on the twoFactor attribute of the LoginState.

What we don't understand is how the value in the send closure of the binding can be true without having sent the loginButtonTapped action in the first place.
The flow should be like this:
2FA state nil -> login button tapped -> request -> 2FA recognised -> 2FA state set -> destination constructed -> navigation active

The send closure indicates that the loginButtonTapped action can only be executed, if the twoFactors attribute is != nil, but the twoFactors attribute can only be != nil if the loginButtonTapped action was executed.
This seems paradox to us.
Even our debug logs are contradictory. The log is from the moment when we tapped the login button.

Can somebody please explain this black magic to us? 😄

[stephencelis]

What we don't understand is how the value in the send closure of the binding can be true without having sent the loginButtonTapped action in the first place.

The send part of ViewStore.binding is the set part of a vanilla SwiftUI binding, which gives the view the ability to influence the value in a source of truth the binding was derived from. We could create a binding from scratch using Binding.init and it would look like this:

Binding(
  get: { viewStore.isTwoFactorActive },
  set: { isActive in
    if isActive {
      viewStore.send(.loginButtonTapped)
    } else {
      viewStore.send(.twoFactorDismissed)
    }
  }
)

So the value in set is sent from the view in order to influence the source of truth, which means the true is what influences the view store from sending the action in the first place. The isActive binding you hand it is true when a user taps the link, and false when a user taps the navigation bar's back button or when they swipe to dismiss. This is of course just the set half of the binding, so the get is free to continue to return false even after set has been fed a value of true.

So the order is:

1. User taps the login button, which feeds a true value to the binding
2. The binding evaluates set and sends loginButtonTapped to the store
3. The store processes the action in the reducer, which fires off a login effect
4. If the login effect returns a 2FA requirement, twoFactor state is initialized, which invalidates the login view state, causing it to recompute
5. The NavigationLink is recomputed, checks its binding's value, which is now true, and presents the two factor screen

[blg-al]

@stephencelis
Thanks for the answer! We really appreciate the hard work of you all with this framework! Awesome stuff