Enum of States. CasePullback.

[myurieff]

Hello folks.

I’ve been using TCA for about a year now and I’m truly excited that we’ve started using it in my jobby-job banking project (with a hundred of thousands user base). We’re close to shipping the first feature with it.
I wanted to walk you through a small problem we had and how we overcame it. It may be considered as a feature request or just me making sure I haven’t done anything stupid.

In the aforementioned feature, we have an input field that can be an arbitrary amount of types - amount entry, date selection, multiple choice, etc.

Initially, I had put all the children input states (AmountEntryState, DateSelectionState, etc) as optionals in the parent InputState. Whichever state is non-optional, that one’s corresponding view gets displayed (by using a couple of IfLetStore).

While the feature is unit tested and we are sure there’s no issue of having two of those states non-optional at any given time, one still can’t help but notice that this is a perfect case for having a switch. There will always be one and only one children state alive at a given point.

So we did a couple of things.
First of all, we made all children states a case of an enum. The parent state has a variable that is of type the enum.

Furthermore, to transform a reducer that works on single case of an enum into one that works on the whole enum, we added casePullback :

    func casePullback<GlobalState, GlobalAction, GlobalEnvironment>(
        state toLocalState: CasePath<GlobalState, State>,
        action toLocalAction: CasePath<GlobalAction, Action>,
        environment toLocalEnvironment: @escaping (GlobalEnvironment) -> Environment
    ) -> Reducer<GlobalState, GlobalAction, GlobalEnvironment> {
        .init { globalState, globalAction, globalEnvironment in
            guard let localAction = toLocalAction.extract(from: globalAction),
                  var localState = toLocalState.extract(from: globalState) else {
                return .none
            }
            let effects = self(
                &localState,
                localAction,
                toLocalEnvironment(globalEnvironment)
            ).map(toLocalAction.embed)
            globalState = toLocalState.embed(localState)
            return effects
        }
    }

So now we can have a small input view like DateSelectionView that works with DateSelectionState and DateSelectionAction and a reducer that works on those types, but can be pulled back and invoked only when the GlobalState enum is a case of .dateSelection(DateSelectionState .

We can continue using IfLetStore for all different cases, but now we need to be able to extract the state from the enum case. To do that, we added a Store.scope overload that uses a CasePath:

extension Store {
    public func scope<LocalState, LocalAction>(
      caseState toLocalState: CasePath<State, LocalState>,
      action fromLocalAction: @escaping (LocalAction) -> Action
    ) -> Store<LocalState?, LocalAction> {
            scope(
                state: toLocalState.extract,
                action: fromLocalAction
            )
    }
}

So now we can show the DateSelectionView only when the parent state enum is .dateSelection(DateSelectionState)

IfLetStore(fieldStore.scope(caseState: /FieldItem.dateSelection, action: AnswerField.Action.date)) { dateSelectionStore in
    DateSelection.Component(store: dateSelectionStore)
}

Finally, to streamline mutations, especially in unit tests, we’ve added a little helper, once again relying on CasePaths.

/** Allows accessing an optional associated value by providing a `CasePath` as a subscript.
 
    Let's say we have an enum:
    ```
    enum Accessory {
        case watch(size: Int)
        case airPods(generation: Int)
    }
    ```
    and a model:
    ```
    struct Person {
        var accessory: Accessory
    }
    ```
    We can directly access the associated value we're interested in:
    ```
    let watchSize = person.accessory[/Accessory.watch]
    ```
    The `watchSize` property is of type `Int?` and will only have a value if
    `person.accessory` is of case `Accessory.watch`.
    Furthermore, we can directly mutate the associated value:
    ```
    person.accessory[/Accessory.watch] = 44
    ```
    This set `person.accessory` to `Accessory.watch(size: 44)`,
    but only if it was the same case with different associated value previously.
 */
protocol CasePathSubcriptable {}
extension CasePathSubcriptable {
    subscript<V>(_ casePath: CasePath<Self, V>) -> V? {
        get {
            if let value = casePath.extract(from: self) { return value }
            return nil
        }
        mutating set {
            if casePath.extract(from: self) != nil, let newValue = newValue {
                self = casePath.embed(newValue)
            }
        }
    }
}

This greatly reduces boilerplate. For example, in unit tests, when we want to assert the date selected, instead of writing this:

               if let answerField = $0.answerField,
                   case AnswerField.FieldItem.dateSelection(let dateSelectionState) = answerField.fieldItem {
                    var copy = dateSelectionState
                    copy.selectedDate = Date(timeIntervalSince1970: 5000)
                    $0.answerField?.fieldItem = .dateSelection(copy)
                }

ugh…
We can write this:

$0.answerField!.fieldItem[/AnswerField.FieldItem.dateSelection]!.selectedDate = Date(timeIntervalSince1970: 5000)

Any feedback would be very much welcomed. Everything works as expected, but if you see any red flags, let me know.

Thank you! ✌️

[AlexisQapa]

FYI there was some similar work done at #82

[lukeredpath]

Yes, FWIW we are using the Path abstraction and optional paths and it works great with the modified pullback and scope functions, no need for special overloads as case paths and key paths have equal support.

For better ergonomics in tests I created a variation on the update function from Overture that works with enum cases:

https://gist.github.com/lukeredpath/ebe3007d2969628b0f8917b1ac0904c5#file-updatepath-swift

Finally you might be interested in my enum take on IfLetStore:

https://gist.github.com/lukeredpath/fde501070878ab3821d4fa41158df31f

Discussion here:

#388

[jtouzy]

For another feedback on this case :

We faced a quite-similar problem in our app, when a component State is represented by an enum (i think this can happen very often on basic components).
We didn't go as far as you, because of another problem: what if someday your state needs a common information shared across all cases of your enum? We didn't want to duplicate the information on all the enum cases.

So we basically just have implemented a classic State, with common informations as root properties, and another property as an enum, named "ContentState" or "ViewState", depending on usages.
The usage is then quite simple: In your view, just switch over your cases to display the corresponding views (our app case was less complex, we didn't have sub-TCA-modules for each enum case). And inside reducer, depending on actions, just set the corresponding enum case in the viewState property.