Improving ergonomics/correctness for State that contains enum values containing child State

[randomeizer]

Hi there,

I'm working on a TCA app with the Observation beta, working with enum State values.

Here is the example for the Reducer/State from the migration guide:

@Reducer struct Feature { @ObservableState enum State { case activity(ActivityFeature.State) case settings(SettingsFeature.State) } enum Action { case activity(ActivityFeature.Action) case settings(SettingsFeature.Action) } var body: some ReducerOf<Self> { /* ... */ } }

...and the matching View:

struct FeatureView { let store: StoreOf<FeatureStore> var body: some View { switch store.state { case .activity: if let store = store.scope(state: \.activity, action: \.activity) { ActivityView(store: store) } case .settings: if let store = store.scope(state: \.settings, action: \.settings) { SettingsView(store: store) } } } }

I am implementing something similar, and while it's better overall than the old SwitchStore/CaseLet implementation, but it's still a bit of a hack.

For one, we're ignoring the state data in the actual .activity(...) state case, and two, we're using an optional scope/state internally with an if let.

What would be great is if we could do this instead:

struct FeatureView { let store: StoreOf<FeatureStore> var body: some View { switch store.scope(state: \.self, action: \.self) { case let .activity(activityStore): ActivityView(store: activityStore) case let .settings(settingsStore): SettingsView(store: settingsStore) } } } }

This means we would need an enum type that looks something like this:

enum Scope { case activity(StoreOf<ActivityFeature>) case settings(StoreOf<SettingsFeature>) }

It's unique to the specific state enum being worked with, so it would have to be either macro-generated or hand-coded. A logical place to put it would be inside the matching state enum.

It could also be publicised as part of a protocol, say CaseScopable:

public protocol CaseScopable: ObservableState { associatedtype Scope: CasePathable }

Our state definition then becomes something like:

struct Feature { @ObservableState struct State: CaseScopable { enum Scope { case activity(StoreOf<ActivityFeature>) case settings(StoreOf<SettingsFeature>) } case activity(ActivityFeature.State) case settings(SettingsFeature.State) } // ... }

Ok, cool. Now we need to implement our caseScope function in Store:

extension Store where State: ObservableState { public func caseScope<ChildState: CaseScopable>( state: KeyPath<State, ChildState>, action: CaseKeyPath<Action, ChildState.Action> ) -> ChildState.Scope { let childScope: Store<ChildState, ChildState.Action> = scope(state: state, action: action) // How to convert our current case into a `Scope` case? } }

However, we also need a way to scope in and out of the type. We could add a function into the CaseScopable enum definition:

public protocol CaseScopable: ObservableState { /// An `enum` with case names that match those in the `CaseScopable` but contain a `Store` that maps to the type. associatedtype Scope: CasePathable /// The action type. associatedtype Action /// Returns a `Scope` enum value for the current case. func caseScope(with store: Store<Self, Action>) -> Scope }

Unfortunately, it requires an Action type reference in order to receive the store.

Now we implement the function:

struct Feature { @ObservableState struct State: CaseScopable { enum Scope { case activity(StoreOf<ActivityFeature>) case settings(StoreOf<SettingsFeature>) } typealias Action = Feature.Action func caseScope(with store: Store<Self, Action>) -> Scope { switch store.state { case .activity: return .activity(store.scope(state: \.activity, action: \.activity)!) case .settings: return .settings(store.scope(state: \.settings, action: \.settings)!) } } case activity(ActivityFeature.State) case settings(SettingsFeature.State) } // ... }

Note that we still have to do a ! 'not nil' force when scoping down, but these should theoretically never be nil if the wrapping case is present.

Now we can call this function in our State.caseScope function:

extension Store where State: ObservableState { public func caseScope<ChildState: CaseScopable>( state: KeyPath<State, ChildState>, action: CaseKeyPath<Action, ChildState.Action> ) -> ChildState.Scope { let childScope: Store<ChildState, ChildState.Action> = scope(state: state, action: action) return self.state[keyPath: state].caseScope(with: childScope) } }

And now our original sketch should compile:

struct FeatureView { let store: StoreOf<FeatureStore> var body: some View { switch store.scope(state: \.self, action: \.self) { case let .activity(activityStore): ActivityView(store: activityStore) case let .settings(settingsStore): SettingsView(store: settingsStore) } } } }

I believe that the implementation for CaseScopable conformance could be put into a macro, but haven't gotten that far.

Things I don't love about it:

1. Having to have an Action associatedtype/typealias in CaseScopable (and thus in the State). Perhaps the Scope enum could go into the Resolver, but State has no actual connection to the Resolver type by default, so it makes writing caseScope harder.
2. The name caseScope could be just scope if this was added into the main library. I needed another name to avoid recursion when scoping down initially. If renamed, this would also prevent accidentally scoping an enum like a struct.
3. I don't love having to force-cast the case-specific store inside caseScope, but I don't think there's any way around it, due to enum type-erasing.

Things I do love:

1. My code in the View is now super-clear.
2. Naming of things could probably use some work.
3. Hard-coding cases is annoying, but should be better with a macro.

Anyway, interested to hear people's thoughts.

[mbrandonw]

Hi @randomeizer, thanks for exploring this! It certainly is interesting, but there are a few things to think about. One thing that comes to mind is dealing with enum cases that hold onto non-TCA features. Like if you needed to present a sheet with a simple value or a vanilla SwiftUI model. The macro would need to handle that gracefully.

Also, switching on store.scope(state: \.self, action: \.self) seems a little strange. Maybe it should just be something like switch store.cases or something. Ideally one could just switch store, but that would require some big changes to Swift to allow for custom destructuring of types with exhaustivity.

And also it seems like this tool could be built outside of TCA proper. I don't think it needs access to any of the internals. That may be the best way to prove its potential for the time being.

[mbrandonw]

Macros don't really have access to type information, right?

That's right. I think the best you can do is just check for a single payload of the form case foo(Bar.State) and hope for the best.

I note that in this case, you're using a CaseLet to resolve it, even though the actual value is being processed in a standard switch?

I'm not sure what you mean. There's no CaseLet when handling that case down in the view:

swift-composable-architecture/Examples/SyncUps/SyncUps/AppFeature.swift

Lines 138 to 139 in 40304a1

	case let .meeting(meeting, syncUp: syncUp):
	MeetingView(meeting: meeting, syncUp: syncUp)

[randomeizer]

I was referring to the other cases in the same switch. My point was more that you're mixing a standard switch and CaseLet to resolve the State enum cases, but not using SwitchStore around it.

Is it essentially functioning equivalently to if let, as in the 1.7 Migration guide? Eg:

case .detail: if let store = self.scope(state: \AppFeature.Path.State.detail, action: \AppFeature.Path.Action.detail) { SyncUpDetailView(store: store) }

[randomeizer]

Can a macro be attached to an enum case? Could possibly have a @CaseScopableIgnored marker if so? Eg:

@ObservableState @CaseScopable enum State: Equatable { case detail(SyncUpDetail.State) @CaseScopableIgnored case meeting(Meeting, syncUp: SyncUp) case record(RecordMeeting.State) }

[randomeizer]

In that case, it would just duplicate the parameters into the Scope.meeting(...) case. Eg:

@CasePathable enum Scope: Equatable { case detail(Store<DetailFeature.State, DetailFeature.Action>) case meeting(Meeting, syncUp: SyncUp) case record(Store<RecordMeeting.State, DetailFeature.Action>) }

[mbrandonw]

My point was more that you're mixing a standard switch and CaseLet to resolve the State enum cases, but not using SwitchStore around it.

The NavigationStackStore bakes a SwitchStore inside it so it is not necessary to use in the code I linked to. I linked to the main version of the code, but you could look at the observation-beta version to see what it looks like in the future.