Store action, state and environment type declaration

[ferologics]

Hi @stephencelis @mbrandonw 👋

I see that you declare Store types in your Pointfree lectures outside the View's scope:

struct FooState {}

struct Foo: View {
  let store: Store<FooState, ...>
}

What is the motivation behind this? What about declaring them instead inside the extension View?

extension Foo {
  struct State {}
}

struct Foo: View {
  let store: Store<State, ...> // <- Foo prefix is implicit
}

The pros of this approach are:

1. No need to rename your FooState if you rename Foo view
2. Shorter use in View's Store property declaration

And the potential cons can be:

1. Static stored properties not supported in generic types (i.e. State.live)
2. Confusing declaration of reducer

Following up on the reducer point:

1. Should reducer be a static let declared inside the extension? Or a static var?
2. Are both static let and static var lazy loaded?

Last but not least, what is the performance tradeoff in global vs scoped extension declarations?

I think your current approach works really well and is consistent, but sometimes the State / Action / Environment names get out of hand and it would be nice to leverage Swift's type inference to improve the readability and use of Store declarations.

Thanks 🙌

[AlexisQapa]

You can get the same results but without nesting in extensions by using a module per screen which is easily achieved with SPM.

In you feature you can then use State, Action, reducer, Environment and Screen (instead of view to avoir conflicts with SwiftUI).
When importing you can have Feature.Screen, Feature.reducer etc ..

One nice addition to this is you can import only what you need like import enum Feature.Action which can be convenient.

[AlexisQapa]

I use xcodegen which is kinda the same thing. I generate a Xcode project with schemes and build actions but the whole app code is in a spm package.

[AlexisQapa]

Thing is, once you are using spm to connect your modules and dependencies you don’t really need much from Xcode.

[ferologics]

@AlexisQapa when I try this I get name collision with SwiftUI.State and Feature.State since they're both declared as State. Any ideas on how to disambiguate the @State from Feature.State? I tried:

import struct SwiftUI.State
public typealias State = SwiftUI.State

but this produces: ❌ Invalid redeclaration of 'State' error 🤷‍♂️

[ferologics]

I guess I would have to drop all @State in the codebase and move it to TCA State 💡

[AlexisQapa]

I use @swiftui.State where needed as Its quite rare when using TCA. You can use the type alias but you need to do it in a separate file which is cumbersome.

[RabugenTom]

Without debating about pros and cons of the "extension" setup, in my TCA Views, I generally use typealiases for State and Action:

struct FeatureView: View {
  typealias State = FeatureState
  typealias Action = FeatureAction
  let store: Store<State, Action>
  …

It is then very convenient to use viewStore.send(Action.doSomething) without thinking twice.
I've also wrote a Xcode extension that generates all the boilerplate (with these typealiases among other things) given a feature name (the text currently being selected). If there's interest, maybe I'll take the time to open-source it.

[ferologics]

Maybe make a Sourcery template for this? Also, any particular reason why you would use Action explicitly? Is the compile time better? as opposed to just viewStore.send(.doSomething)

[RabugenTom]

The explicit Action was just some short example and is indeed not needed here.
I'm using it principally to scope the store, where I was tired of typing the whole thing. I also had issues with viewStore's bindings where autocompletion almost never work, so I think I'm using it there too.

I don't have Sourcery template for this as I'm generating the whole boilerplate only once when creating a feature. Here is the kind of template I'm using. Replace XXX and xXX with your feature name:

import ComposableArchitecture
import SwiftUI

// MARK: - State
struct XXXState {
    var view: XXXViewState = XXXViewState()
}

struct XXXViewState: Hashable {

}

// MARK: - Action
enum XXXAction: Equatable {
    case noop
}

// MARK: - Environment
struct XXXEnvironment {
    typealias Action = XXXAction
}

// MARK: - Reducer
let xXXReducer = Reducer<XXXState, XXXAction, XXXEnvironment>.combine(

    Reducer<XXXState, XXXAction, XXXEnvironment> {
        state, action, environment in
        switch action {
        case .noop :
            return .none
        }
    }
)

// MARK: - View
struct XXXView: View {
    typealias S = XXXState
    typealias A = XXXAction
    typealias V = XXXViewState

    init(store: Store<S, A>) {
        self.store = store
        self.viewStore = ViewStore(store.scope(state: \.view))
    }
    
    let store: Store<S, A>
    @ObservedObject var viewStore: ViewStore<V, A>
    
    var body: some View {
        Text("XXXView")
        .frame(maxWidth: .infinity, maxHeight: .infinity)
    }
}

// MARK: - Preview
struct XXXView_Previews: PreviewProvider {
    static var previews: some View {
        XXXView(store: .init(initialState: .init(), reducer: xXXReducer, environment: .init())).padding()
    }
}

Usually, my view state property is read-only and built from other state's fields.

[stephencelis]

There are a few reasons we like defining the domain of a feature outside of its view:

• Because the view depends on the domain and the domain does not depend on the view, this means you can extract the domain of a feature into its own module that can be tested in isolation.
• By decoupling the domain from the view it means you can reuse a domain across many different views. This could be as simple as skinning a feature differently (maybe preparing a new view to be A/B tested), or as complex as defining completely separate macOS and iOS and tvOS views for the same feature.
• While a lot of the time there are entry points for a feature's root view that contains a store of root state and root actions, when you begin to scope things to sub views, views often have their own subset of state they care about. We typically nest these domains in the view as view-specific domain. This means when you encounter FeatureView.State you can know that it is only the state that FeatureView cares about observing and nothing else.

Should reducer be a static let declared inside the extension? Or a static var?

We still like to define reducers at the module-level for apps/features. We occasionally define reducers in extensions of the Reducer type, though, especially "higher-order reducers". I think it's common to use let if the reducer is a value, and var (or func) if it's computed. I'm sure there are reasons to use var to allow the value to be mutated, but that would seem to be rare and potentially dangerous!

Are both static let and static var lazy loaded?

I think Swift uses a "dispatch once"-like mechanism for both when they are constants.

Last but not least, what is the performance tradeoff in global vs scoped extension declarations?

I'm not aware of any 😄

We go into these particular concepts in further depth in some of the Point-Free episodes, particularly the sections on modularity and adaptation. And I'm sure we'll dive deeper into things in the future!

[ferologics]

Awesome, thanks for the in depth response, this checks all the major points!

the view depends on the domain and the domain does not depend on the view

I hear proper domain modeling and I just say: YES. 😄

By decoupling the domain from the view it means you can reuse a domain across many different views

Oh I didn't even consider A/B testing, that's a very good point.

This means when you encounter FeatureView.State you can know that it is only the state that FeatureView cares about observing and nothing else

We've been doing this in some of our Feature specific views and it's what inspired my question to begin with :)

Pointfree ergonomics have been restored, thx!