IfCaseLet Pullback

[PorterHoskins]

I typically use an enum to model modal features in my app. For example:

struct Feature: ReducerProtocol {
   struct State: Equatable {
      var route: Route
   
      enum Route: Equatable {
         case modal(ModalFeature.State)
         case none
      }
   }
}

How would you use ifCaseLet to compose these features? I am currently running into the following issue:

Static method 'buildExpression' requires the types 'Feature.State' and 'Feature.State.Route?' be equivalent.

I might be doing it wrong but this is what I’m doing:

.ifCaseLet(/State.Route.modal, action: /Action.modal) {
    ModalFeature()
}

Is there a way to get this working or should I consider modeling the state differently?

[PorterHoskins]

Maybe getting a little closer. Now with the following code I get:
cannot convert value of type 'OptionalPath<Feature.State, ModalFeature.State>' to expected argument type 'CasePath<Feature.State, ModalFeature.State>'

.ifCaseLet((\State.route).appending(path: /State.Route.modal), action: /Action.modal) {
    ModalFeature()
 }

Is there a way to get a CasePath instead of an OptionalPath in this scenario?

[gohanlon]

Hi Porter! Could provide a sample project for others to toy around with and serve as a common frame of reference?

[mbrandonw]

I think we are missing the tool that makes it possible to first single out an enum field in your state, and then destructure it for running child reducers on each case.

Without resorting to optional paths (which are still experimental and only really exist in the isowords code base), there's a hacky thing you can try:

var body: some ReducerProtocol<State, Action> {
  Scope(state: \.route, action: Action.route) {
    EmptyReducer()
      .ifCaseLet(...)
      .ifCaseLet(...)
      .ifCaseLet(...)
  }
  Reduce { state, action in 
    // Parent logic
  }
}

It's not great, but it should help you move forward. We will think more about what this tool should look like.

It's also worth mentioning that the navigation APIs we are cooking up will also largely alleviate the need for this hack or optional paths, which will be nice.

[PorterHoskins]

That worked great. Thanks!

Excited for the navigation stuff 🎉

[stephencelis]

@PorterHoskins As an aside, @HarshilShah pointed out that the above sketch could probably be modeled a lil more safely, so I tried to explain how to do so with the current tools here: #1297 (comment)

[stephencelis]

@BornaMajstorovic Can you elaborate as to what specifically is no longer working, ideally with a repro we can troubleshoot?

[BornaMajstorovic]

@stephencelis Sorry, problem was on my end :)

[HarshilShah]

I have a similar setup for routing, and so I've written some helpers to help with this. I've got two base protocols for the state and action:

public protocol RoutableState {
	associatedtype Route
	var route: Route? { get set }
}

public protocol RoutableAction {
	associatedtype Route
	static func setRoute(_ route: Route?) -> Self
}

and then this new Reducer function, with code largely based on _IfLetReducer.

extension ReducerProtocol where State: RoutableState, Action: RoutableAction {
	func route<Destination: ReducerProtocol>(
		path toLocalState: CasePath<State.Route, Destination.State>,
		action toLocalAction: CasePath<Action, Destination.Action>,
		@ReducerBuilderOf<Destination> then destination: () -> Destination,
		file: StaticString = #file,
		fileID: StaticString = #fileID,
		line: UInt = #line
	) -> RoutingReducer<Self, Destination> {
		RoutingReducer(
			parent: self,
			local: destination(),
			toLocalState: toLocalState,
			toLocalAction: toLocalAction,
			file: file,
			fileID: fileID,
			line: line
		)
	}
}

struct RoutingReducer<Parent: ReducerProtocol, Local: ReducerProtocol>: ReducerProtocol where Parent.State: RoutableState, Parent.Action: RoutableAction {
	@usableFromInline let parent: Parent
	@usableFromInline let local: Local
	@usableFromInline let toLocalState: CasePath<Parent.State.Route, Local.State>
	@usableFromInline let toLocalAction: CasePath<Parent.Action, Local.Action>
	@usableFromInline let file: StaticString
	@usableFromInline let fileID: StaticString
	@usableFromInline let line: UInt
	
	@inlinable
	init(
		parent: Parent,
		local: Local,
		toLocalState: CasePath<Parent.State.Route, Local.State>,
		toLocalAction: CasePath<Parent.Action, Local.Action>,
		file: StaticString,
		fileID: StaticString,
		line: UInt
	) {
		self.parent = parent
		self.local = local
		self.toLocalState = toLocalState
		self.toLocalAction = toLocalAction
		self.file = file
		self.fileID = fileID
		self.line = line
	}
	
	@inlinable
	func reduce(
		into state: inout Parent.State, action: Parent.Action
	) -> Effect<Parent.Action, Never> {
		return .merge(
			self.reduceLocal(into: &state, action: action),
			self.parent.reduce(into: &state, action: action)
		)
	}
	
	@inlinable
	func reduceLocal(
		into state: inout Parent.State, action: Parent.Action
	) -> Effect<Parent.Action, Never> {
		guard let localAction = toLocalAction.extract(from: action) else {
			return .none
		}
		
		guard var localState = toLocalState.extract(from: state.route) else {
			print("Action \(localAction) was sent despite the state being nilled out")
			return .none
		}
		
		defer { state.route = toLocalState.embed(localState) }
		
		return local.reduce(into: &localState, action: localAction)
			.map(toLocalAction.embed)
	}
}

So at the call site it ends up becoming:

var body: some ReducerProtocol<State, Action> {
	Reduce { /* reducer goes here */ }
	.route(path: /State.Route.modal, action: /Action.modal) {
		Modal()
	}
}

The one big "gotcha" here is that the TCA runtime warnings stuff is internal so I can't use that, and instead I'm just printing stuff to the console.

[RuiAAPeres]

Was there any progress regarding this problem? In particular a state that has the following shape:

struct State {
  enum Status {
     case x(X)
     case y(Y)
  }

  var status: Status = ...
  var somethingElseCommonToBothCases = ...
}

And the corresponding helpers at the SwiftUI level with SwitchStore.

Thank you. 🙇‍♂️

[stephencelis]

Brandon posted a solution above, and our planned nav tools will generally improve the situation, though not sure they will apply to your truncated example.

If you share more of your working domain and any problem you're having we might have a better opportunity helping 😄

[RuiAAPeres]

For example I have a Settings screen, that exists independently of x or y.

[stephencelis]

@RuiAAPeres I mean if you could post a full, compiling (or almost-compiling) version of your reducer and its domain, or approximation thereof. You're not giving folks a ton to go off yet. TCA definitely has the tools, but you need to share a fuller example if you want us to be able to help you use them 😅

[RuiAAPeres]

That's fair! Unfortunately I can't do it at this point with the existing project. :/ I will try to figure out something on the meantime. Thank you for the replies!