Centralize Reducer.body Scope object and Store.scope into one object

[patch-benjamin]

Intro

I'm fairly new to TCA, but have run into a pain point that I think is largely solvable (assuming my pain point is not due to a misunderstanding):

• Embedding a State into another State requires 2 separate Scope calls (one of which takes a CasePath, the other taking a closure/enum case):
  • Reducer.body - Scope(...) (takes a CasePath)
  • View.body - NewView(store: store.scope(...) (takes a (ChildAction) -> Action - i.e. an enum case)

Problem:

1. The duplication of Scoping seems unnecessary. If we define how to scope from one State/Action to another State/Action (i.e. from one Reduce to another Reducer) in one place then we should be able to leverage that logic elsewhere when needed.
2. I personally have frequently forgotten to add the Scope object to my Reducer.body variable. Debugging this mistake is PAINFULL. Everything builds and runs, but suddenly things just don't work as expected... Bindings don't get updated at all, buttons don't trigger navigation like they're setup to, etc. You get the purple warnings, but those can be missed if you're not looking for them.

Suggested Solution:

I believe we can improve the current solution by slightly altering the Scope object (or in my code example below create a SafeScope wrapper around it) and adding a Store.scope function that takes a SafeScope object.

##Code:

import ComposableArchitecture

// MARK: - SafeScope

/// This object exists to ensure `toChildAction` is not a `CasePath` because that would require
/// an optional initializer, which would be annoying to deal with in the `var body` of the `Reducer`.
public struct SafeScope<ParentState, ParentAction, Child: ReducerProtocol> {

    public let scope: Scope<ParentState, ParentAction, Child>// maybe not needed.

    public let toChildAction: CasePath<ParentAction, Child.Action>
    public let toChildSafeKeyPath: WritableKeyPath<ParentState, Child.State>

    @inlinable
    public init(
      state toChildState: WritableKeyPath<ParentState, Child.State>,
      action toChildAction: @escaping (Child.Action) -> ParentAction,
      @ReducerBuilderOf<Child> _ child: () -> Child
    ) {
        let childAction = CasePath<ParentAction, Child.Action>(toChildAction)
        self.toChildAction = childAction
        self.scope = .init(state: toChildState, action: childAction, child)
        // TODO: Figure out how to make `Scope.StatePath.casePath` work when it doesn't return nil.
        self.toChildSafeKeyPath = toChildState
    }

}


// MARK: - ScopeOf

public extension ReducerProtocol {
    // This exists for convenience when declaring a Scope object on the Reducer.
    typealias ScopeOf<ChildReducer: ReducerProtocol> = SafeScope<State, Action, ChildReducer>
}


// MARK: - SafeScope -> Store

public extension Store {

    // This function allows a `Scope` object (or rather a `SafeScope` object) to be re-used 
    // when initializing a `View` and scoping a `Store`.
// TODO: Ideally `_ scope` would take a `KeyPath<Store.Reducer, SafeScope>`. This would allow for the call site to be like:
// `NextView(store: store.scope(\CurrentReducer.nextViewSafeScope)`
// Or in less verbose syntax:
// `NextView(store: store.scope(\.nextView)`
    func scope<ChildReducer: ReducerProtocol>(
        _ scope: SafeScope<State, Action, ChildReducer> 
    ) -> Store<ChildReducer.State, ChildReducer.Action> {
        return self.scope { parentState in
            parentState[keyPath: scope.toChildSafeKeyPath]
        } action: { childAction in
            scope.toChildAction.embed(childAction)
        }
    }
}

Implementation Code

The above change allows for the following implementation, which I think is preferable to the way I was doing it (assuming I was doing it correctly):
Caveat: the code below was typed in-browser, so it's not compiler guaranteed...

struct Reducer1: ReducerProtocol {
  static let reducer2: ScopeOf<Reducer2> = .init(state: \.reducer2State, action: Action.reducer2Action) {
    Reducer2()
  }
// The above is easier to type than both other Scope options currently because `action` ONLY takes a 
// and you no longer have to type `SomeLongReducerProtocolInstanceName.Action.reducer2.Action`
// and instead will always start with the easy `Action.` to access your Action-scoping closure/enum.
...
  struct State: Equatable {
    var reducer2State: Reducer2.State
...
  }
  enum Action: Equatable {
    case reducer2Action(Reducer2.Action)
...
  }

  var body: some ReducerProtocol<State, Action> {
...
    Self.reducer2.scope 
// No need to remember to use CasePath here (or deal with the regex autocomplete to typing `/`)
...
  }
}

Then the View can re-use that scope:

struct View1: View {
  var store: StoreOf<Reducer1>
...
  var body: some View {
... 
// <some trigger to show View2>
    View2(store: store.scope(Reducer1.reducer2)
// No more need to remember that you don't use CasePath here. 
// Also, no need to specify the Reducer's Type before the Action case like `Reducer1.Action.reducer2Action`
// This can be annoying when your reducer has a large name like `CreateAccountVerifyAccountReducer.Action.childAction`

// The above syntax could also be simplified to this:
    View2(store: store.scope(\.reducer2)
...
  }
}

Potential Problems:

1. The Scopes/States I've been dealing with have all been fairly basic. This approach should allow for injection Dependencys into the scoped Reducers, but might break down if you need to initialize your Scoped reducer with some value... i.e. - static let reducer2: ScopeOf<Reducer2> = .init(...) { Reducer2(someValue: <what do we put here?>, ...)
2. I'm working on the assumption that State is a struct in both sides of the scoping, which is not always true. So this may break down with different forms of State or Action.
3. There are probably more issues that I haven't considered...

Potential Awesomeness:

1. With all the required Scopes being defined on the Reducer type, there might be a possibility of creating an auto-implemented var scopes on the ReducerProtocol that uses reflection or something to grab the scopes defined on itself and inject them into the body automagically. That would mean you wouldn't need to "add" the scopes anywhere in the Reducer besides declaring them (in a specific place).
2. If the Store gained access to it's Reducer type (and the ScopeOf variable declarations were instance variables instead of static variables as I have it written above), Store could implement dynamicMemberLookup to the Reducer type and allow syntax like: View2(store: store.reducer2) (where Reducer1 has an instance variable of var reducer2: ScopeOf<Reducer2> = .init....

Outro

I'd love feedback on this idea.
Firstly, are my assumptions/understandings of the requirements of TCA off? Does something like this already exist that I just don't know about?
If you're using TCA differently from the above examples, would the above code break you?
Would it benefit you? If not, are there alterations of it that it could benefit your usage of TCA?

[Alex293]

This makes sens only in very simples cases. Here are my 2c why. Scoping at the view level is used to control how often a view rerenders and so should be scoped as narrow as possible while scoping at the reducer level allows composition and reuse of logic. Lets say you build some kind of form, you could have a reducer per field, a reducer for validation etc while at the view level you could have a single viewstore. Disregarding my example I‘d expect to have far more viewstore scoping than reducer scoping especially when working with collections where you want to be precise about view rendering. Obviously how you split your features is deeply connected to what you want to achieve so take my comment with a grain of salt.

[patch-benjamin]

Super interesting feedback @Alex293 ! Like I said I'm newer to TCA and haven't dealt with forms or lists as of yet (I've been mostly focused on an Auth flow so far). I do know there are some gotchas around lists and TCA...
If you have a code example of your above scenario that would be super helpful for me personally. But most of us have busy lives, so if not that's fine too :)

[Alex293]

I don't have code for this, it was more of a thought exercise :p, have a look at isowords for a complete example.

I tend to think scoping viewStore as a frontend part for the feature while scoping a reducer is more of a backend thing. In simple features they match but in more complexe cases a front end might be served my multiple backend feature like a dashboard while a single backend feature might serve multiple front end feature.

Now I don't know if this strange idea will help you or confuse you

[stephencelis]

2. I personally have frequently forgotten to add the Scope object to my Reducer.body variable. Debugging this mistake is PAINFULL. Everything builds and runs, but suddenly things just don't work as expected... Bindings don't get updated at all, buttons don't trigger navigation like they're setup to, etc. You get the purple warnings, but those can be missed if you're not looking for them.

Can you share a full, building example of this? I'm having a hard time understanding how a parent reducer would succeed to build with a child embedded in it without the Scope.

[patch-benjamin]

If you want the full project, here it is:
TCA_ScopeExample.zip

[stephencelis]

@patch-benjamin Ah, I see, not only is Scope forgotten, but ChildReducer doesn't appear at all in the ParentReducer's body. This is exactly what I would expect to happen, unfortunately, but I'm not sure we can do much about it.

This is the ReducerProtocol equivalent of forgetting to add a ChildView to a ParentView in SwiftUI: the child view's simply not going to show up in the view hierarchy. While I do understand that it's probably easier to catch a visual omission (if you run the app and go to the screen, or load an Xcode preview), the purple warnings are emitted for the exact same diagnostic reason. And you would catch the problem more loudly if you use the TestStore to write a test against the ParentReducer's integration with ChildReducer, which produces an XCTest failure instead of a purple warning.

As for your suggested solution, in addition to the "potential problems" you lay out, it also couples ParentReducer's ChildReducer integration to the Store/View layer, which means you wouldn't be able to write the parent-child integration tests I just mentioned at all (without duplicating this functionality on TestStore and remembering to invoke it in both the view and test layers). Also, there are many compositional operators in addition to Scope, like ifLet, ifCaseLet, forEach, BindingReducer, and more (some folks have probably even defined their own outside the library). If you omit any of these in the ReducerProtocol's body you'll run into the same issues. At the end of the day, if a reducer/operator doesn't appear in a reducer's body, we can't expect it to be integrated.

The biggest actionable thing I can think of is your comment around the purple warning not being "easy to overlook." Originally, we raised a breakpoint signal, which is much louder, but also much more disruptive and confusing (it caused many TCA library users to think their application crashed). We still think the purple warning is the preferable, less invasive default, but we could potentially introduce some configurability, so that you could do something like:

ParentReducer()
  .dependency(\.warningLevel, .breakpoint)

Does that sound like a configuration option you'd want to opt into?

[patch-benjamin]

it also couples ParentReducer's ChildReducer integration to the Store/View layer

I'm not sure I understand that statement. Is there a Case Study or example somewhere that shows a Parent/Child reducer integration test? I'm not super familiar with TestStore yet...

Does that sound like a configuration option you'd want to opt into?

1. Ya, I would probably turn that on -- if not always at least while debugging.
2. The provided example in my reply above (the one not using @BindableState) wasn't showing Purple warnings when I ran it. Is that accurate? If so, then this would only solve the issue for binding action cases being fired, right?

I would love it if there were some way to get compile warnings if you forget to add a scope in the body... Like if there were a separate enum for ChildAction mappings and body forced you to provide a Reducer for each case of ChildAction or something... 🤷
I would also love it if there were a way to unify the toChildAction type in Scope and store.scope.

[patch-benjamin]

Also, thanks for the prompt reply! ❤️

[stephencelis]

I'm not sure I understand that statement. Is there a Case Study or example somewhere that shows a Parent/Child reducer integration test? I'm not super familiar with TestStore yet...

Definitely check it out! Testing is probably one of the biggest value adds the library provides 😄

Here's an abstract example of testing a Scope in the repo here:

swift-composable-architecture/Tests/ComposableArchitectureTests/ScopeTests.swift

Lines 6 to 24 in f56a0d1

	func testStructChild() async {
	let store = TestStore(
	initialState: Feature.State(),
	reducer: Feature()
	)
	await store.send(.child1(.incrementButtonTapped)) {
	$0.child1.count = 1
	}
	await store.send(.child1(.decrementButtonTapped)) {
	$0.child1.count = 0
	}
	await store.send(.child1(.decrementButtonTapped)) {
	$0.child1.count = -1
	}
	await store.receive(.child1(.incrementButtonTapped)) {
	$0.child1.count = 0
	}
	}

Note that if the reducer being tested forgot to include the Scope and child reducer in its body the test would fail, either logically (state didn't update to the expectation), or by promoting one of the purple runtime warnings we emit to a full XCTest failure.

This is what I mean by your proposed operator is coupled to the view. The integration is kinda stuck in store.scope, which appears in the view, and is otherwise unconnected to ParentReducer. That means you'd need to re-integrate parent and child in each test using a theoretical TestStore.scope operation.

2. The provided example in my reply above (the one not using @BindableState) wasn't showing Purple warnings when I ran it. Is that accurate? If so, then this would only solve the issue for binding action cases being fired, right?

Binding actions sent to reducers that don't embed a binding reducer emit a purple warning, yep, but it's an ad hoc diagnostic.

I would love it if there were some way to get compile warnings if you forget to add a scope in the body... Like if there were a separate enum for ChildAction mappings and body forced you to provide a Reducer for each case of ChildAction or something... 🤷

I just don't see how this is possible. It'd be like a ParentView failing to compile if a ChildView isn't specified in its View.body in SwiftUI. Open to ideas, though!