Should Store and Effect evolve towards protocols?

[tgrapperon]

Without spoiling things, it is very likely that, in a near future, TCA will adopt typed (or protocolized) reducers. In other words, reducers will be values of types that conform to a protocol instead of merely being values of Reducer<State, Action, Environment>. Reducers will likely be types that conform to the ReducerProtocol which has two associated values: State and Action; the Environment being dissolved into a set of Dependencies that are exposed at will by the reducers. Usual reducers as we know them will continue to work, and adoption could be piecemeal.

This transition invites reflection on performing this abstraction with other types in the library.

The first candidate is the Store. Right now, it is a class, generic over its State and Action. Because they have the same generic signature, this information could be supported by Reducers instead. We can lias a StoreOf<Reducer> == Store<State, Action>, but we lose the type of Reducer while doing so, and we miss interesting specializations/optimizations where the Reducer type could play a role. If StoreProtocol<Reducer: ReducerProtocol> was a protocol, we could be able to alias the current stores as Store<AnyReducer<State, Action>>, but also allow to conform other types to StoreProtocol like TestStore of course, but even actors, opening the way to async stores/reducers. The ControlledStore I presented as an experiment in #1176 is another example where we could have added additional behaviors to a Store in a more streamlined way if we would only have to conform to a protocol.

The second candidate is Effect. Right now, Effects are merely a wrapper of a publisher. Having them conform to a protocol (or maybe simply an enum) could potentially allow coalescing/simplifying reducers outcomes. Right now, it is quite inconvenient to poke inside an effect, and if they were more structured, we could probably post-process them in a more subtle manner. Furthermore, it is also likely that the library will try to cut its deep ties with Combine. Effects being protocols could probably allow both systems to cohabit for a while and ease the migration.

I'm not proposing any interface to these hypothetical protocols. I'm just starting the discussion in case some of you have interesting ideas on the matter!

[JacksonUtsch]

Effect is essentially an AnyPublisher equivalent which is just a type eraser for Publisher (the main combine protocol). Type erasure has been used because of language limitations. The use of any and constrained types should allow for removing type erasure. I think we can use this as soon as Publisher has a primary associatedtype defined in its protocol declaration.

So, once this is implemented migrate could take place. The extensions on Effect could be moved to Publisher. Sounds good to me.

[kamcma]

I think Publisher got primary associated types in Xcode 14b2: https://twitter.com/DonnyWals/status/1541039200828641281

[mbrandonw]

We will definitely be adopting any Publisher<Output, Failure> in some way to improve the ergonomics of effect once it's ready. It'll have to be gated to only Swift >=5.7, and we can't even get a beta version in place right now due to this compiler crash: swiftlang/swift#59708

[mbrandonw]

We think Effect as a protocol (or enum) is mostly a no-braniner. It would be good in order to, as you say, retain some static information about the effect so that we can do certain things, such as squash .none effects and fusing merges. That should bring some performance benefits to the construction and running of effects, and possibly unlock some other interesting things (@tgrapperon: curious about how you would have used this for ControlledStore!).

Store as a protocol could also be interesting, but it's hard to imagine what it could look like. Due to the nature of store scoping, it seems that a store protocol would need to expose get/set on its state, which is too big of an escape hatch to expose. I think we have to think a lot more about how that could look.

[tgrapperon]

My idea for ControlledStore was more about protocolized Stores than Effects, but as I'm thinking about it, I now wonder if we could cook up all the actions being programmed into one big effect. It is maybe already possible with what's coming up regarding concurrency-updates, but it would be processed by the app's Store, which was something I wanted to avoid in the first place.
At the Store level, I was thinking about controlling a store without changing its type too much while hosting the controller store. This is the same thing that could probably be achieved with a subclass of Store if instances were reused when scoping. Basically, if FeatureView(store: any Store<some Reducer>), we would be able to install the controller in parallel without having to update the clients or use the SwiftUI view with the odd signature (S,…, (S) -> some View) where S: Store, and directly write:

FeatureView(store: store)
// or
FeatureView(store: store.controlled{…})

---

it seems that a store protocol would need to expose get/set on its state

I have the feeling/hunch that the fundamental operation of a store is scoping. Even being able to receive actions or activate reducers feel secondary (but I may be completely wrong on this point!).
For example:

protocol StoreProtocol<Reducer>
  associatedType: Reducer: ReducerProtocol
  typealias State = Reducer.State
  typealias Action = Reducer.Action

  func scope<LocalReducer>(
    state: (State) -> LocalReducer.State, 
    action: LocalReducer.Action -> Action
  ) -> some Store<LocalReducer>
}

ViewStore could either be themselves protocolized, or restricted to compatible Stores. Other requirements would likely cause too many constraints on the possible conformances (for example being state or send() being async or sync for example), and sub-protocols may be introduced if required. Furthermore, the Reducer associated type could also be generalized to accept hypothetical async reducers, but in this case, it would probably be more convenient to wait for reasync to explore what's possible with the tools will have at this point.

My initial and principal motivation for Stores being protocol was to allow some Store<Reducer> and some Store<State, Action> to coexist. TestStore is already working, so this is not really a concern, even if it would be aesthetically pleasing to have it as a bonafide Store. Async/actor stores and such are highly hypothetical.

[tgrapperon]

@mbrandonw As I'm still thinking about the big Effect to control stores, I wonder what it would look like if Store had an initialEffect (defaulting to .none), similar to initialState. Some effect that is sent just after initialization, without involving any external lifecycle consideration like SwiftUI's onAppear, etc. It would probably allow some interesting new behaviors (good or bad, I don't know!). For example, you can have the insurance that a store has subscribed to a publisher in the environment, regardless of the state of the UI. I don't know how it would work with respect to scoping, especially since we don't reuse instances. I'll experiment with that!

[tgrapperon]

Another use-case for StoreProtocol would be the ability to have @MainActor locked Stores (without going as far as making them actor themselves), and @MainActor locked ViewStores. As I'm getting it, these objects can also be Sendable when the State is Void, as the only thing we can do in this case is sending actions to the store, and this function can be isolated to @MainActor. Of course, unconstrained Store and ViewStore types would also be provided.

This could have proved useful when reimplementing ControlledStore functionality using one big "run-like" Effect to encode the program, with a Send that wraps ViewStore.send. I have very encouraging results in this direction, but I have a few warnings that I can't seem to avoid without weakening concurrency warranties¹. I'll push farther once the new concurrency affordances are released.

We could also have class Store: StoreProtocol, a convenient @MainActor store, with its associated ViewStore: ViewStoreProtocol, and actor BackgroundStore: StoreProtocol another kind of store, with their associated actor: BackgroundViewStore. This kind of setup could help interfacing UI stores and background ones, and maybe open a way to structure features as self-contained (Store + BackgroundStore) that could be composed/scoped pairwise to build up larger domains.

Footnotes

1. As I'm using a standard ViewStore<Void, Action> wrapped in a Send<Action> to send actions asynchronously, I need to make it Sendable. As I'm getting it, this would be for example possible if I had a ViewStore that is marshalling its .send(_:Action) calls with a global actor. With a @MainActor Store and a @MainActor ViewStore I would have this guarantee. This would of course limit the functionality to such stores for now. ↩

[jonsteinmetz]

We think Effect as a protocol (or enum) is mostly a no-braniner. It would be good in order to, as you say, retain some static information about the effect so that we can do certain things, such as squash .none effects and fusing merges. That should bring some performance benefits to the construction and running of effects, and possibly unlock some other interesting things (@tgrapperon: curious about how you would have used this for ControlledStore!).

Has any further thought been put into Effects as enums? I apologize if I have missed something but I have fallen behind on the videos and am working to catch up. The architecture I have been using is actually a variant of TCA from before it was published on github and actually uses enum Effects.
One aspect of effects as publishers or functions is that IMO the reducer function cannot really be considered "pure" since the output is not inherently equatable (unless I am mistaken).