Optional paths?

[lukeredpath]

We've been using the OptionalPaths helper for a while and I was wondering if there was any plans to ship with support for this with the final protocol reducers release or if the need for this is made redundant somehow by newer APIs?

If it helps anyone, this is what I came up with to add support for OptionalPaths using a pre-beta branch of protocol reducers when I experimented with it. It will likely need some tweaking and renaming to make it fit with the beta:

extension ReducerProtocol {
  public func pullback<GlobalState, GlobalAction, StatePath, ActionPath>(
    state toLocalState: StatePath,
    action toLocalAction: ActionPath
  ) -> PullbackPath<StatePath, ActionPath, Self>
  where
    StatePath: Path, StatePath.Root == GlobalState, StatePath.Value == State,
    ActionPath: Path, ActionPath.Root == GlobalAction, ActionPath.Value == Action
  {
    PullbackPath(state: toLocalState, action: toLocalAction) {
      self
    }
  }
}

public struct PullbackPath<StatePath: Path, ActionPath: Path, Local: ReducerProtocol>: ReducerProtocol
where
  StatePath.Value == Local.State,
  ActionPath.Value == Local.Action
{
  public typealias State = StatePath.Root
  public typealias Action = ActionPath.Root
  
  @usableFromInline
  let toLocalState: StatePath

  @usableFromInline
  let toLocalAction: ActionPath

  @usableFromInline
  let localReducer: Local

  @inlinable
  public init(
    state toLocalState: StatePath,
    action toLocalAction: ActionPath,
    @ReducerBuilder<Local.State, Local.Action> _ local: () -> Local
  ) {
    self.toLocalState = toLocalState
    self.toLocalAction = toLocalAction
    self.localReducer = local()
  }

  @inlinable
  public func reduce(
    into state: inout State, action: Action
  ) -> Effect<Action, Never> {
    guard let localAction = toLocalAction.extract(from: action)
    else { return .none }

    guard var localState = toLocalState.extract(from: state)
    else { return .none } // TODO: add runtime warning for nil state back
    let effect = localReducer.reduce(into: &localState, action: localAction)
      .map { localAction -> Action in
        var action = action
        toLocalAction.set(into: &action, localAction)
        return action
      }
    toLocalState.set(into: &state, localState)
    return effect
  }
}

[stephencelis]

Good question! While we're open to introducing optional paths to the Case Paths library, we aren't really happy with the current API, which is simple and works, but is also inflexible compared to Swift's native key paths (no ability to erase, loss of reference-writability, etc.). We also think that ideally case paths and optional paths work their way into the language natively.

or if the need for this is made redundant somehow by newer APIs?

We think that some of the APIs we've sketched out will make optional paths much less needed, particularly around navigation.

The primary uses of optional paths in isowords were for navigation, where we have layers of optional enum state that need to be unwrapped. If navigation is the primary use for optional paths, we think it might be better to design navigation APIs explicitly around this nested shape.

In fact, this is a learning we employed in SwiftUI Navigation, where we separate the optional route endpoint from routing case path:

https://github.com/pointfreeco/swiftui-navigation/blob/7191be709528b0d0040105c7071d35fbb923d462/Sources/SwiftUINavigation/Sheet.swift#L70-L78

These unwrapping:case: overloads are technically not needed, as you could compose the binding instead using Binding.case(_: CasePath) (which is what the implementations are doing under the hood in a single line), but we think that overloads provide better surface area to plug into, and don't require the library user to know how to transform a binding with a case path.

We're designing TCA navigation APIs with this same consideration in mind, and so we do think we can hold off on shipping optional paths.

How are you using optional paths in your application? Is it primarily around navigation or have you found other uses?

[lukeredpath]

Off the top of my head I would think that we are using this for navigation for the most part, yes. I'm looking forward to seeing what you have come up with to improve TCA navigation, I'm curious if this will only work with the new navigation stack APIs or will also work with the older APIs because we're likely to be stuck with those for at least another year or so.

[stephencelis]

I'm curious if this will only work with the new navigation stack APIs or will also work with the older APIs because we're likely to be stuck with those for at least another year or so.

Our most recent experiments work with navigation stacks, but we intend to bring in support for the old style of NavigationLink, as well.