Mini-beta: @Reducer+@CasePathable macro bonanza

[stephencelis]

We just opened a PR introducing some exciting new functionality to the Composable Architecture and would love your feedback before release. Be warned, we will have episodes diving into some of these tools soon, so if you don't want those topics spoiled, read no further!

Introducing: the @Reducer macro

There is a new @Reducer macro that can be used to define features in the Composable Architecture.

Where one used to conform to the Reducer protocol, they can now apply the @Reducer macro instead:

-struct Feature: Reducer { … }
+@Reducer struct Feature { … }

The macro automatically conforms the type to the Reducer protocol, but it does a few more things along the way:

1. It automatically annotates Action enums with the new @CasePathable macro, which generates "case key paths" for your actions, which are actual Swift key paths that improve on the old, reflection-based API (/SomeEnum.someCase) in many ways, including type inference, autocomplete, equatability and hashability, dynamic member lookup, performance, and more.

   All case path-based APIs in the library have been updated to support the new format:

   -Scope(state: \.child, action: /Action.child) {
   +Scope(state: \.child, action: \.child) {

2. It automatically annotates State enums (commonly found in TCA navigation) with @CasePathable, as well as @dynamicMemberLookup. This will allow you to slightly improve the verboseness of TCA's enum navigation tools:

    .sheet(
      store: self.store.scope(state: \.$destination, action: { .destination($0) }),
   -  state: /Destination.State.add,
   -  action: Destination.Action.add
   +  state: \.add,
   +  action: { .add($0) }
    )

   Because @Reducer automatically applies @CasePathable inside, you largely won't have to worry about the @CasePathable macro unless you want to work with other enums in an ergonomic fashion.

3. It does some basic linting of your conformance.

TestStore.receive(\.action)

There is a new method on test stores for matching received actions via a case key path.

await store.receive(\.response)

Case key paths chain nicely, which makes it possible to describe expected actions in a lightweight manner, even in the deepest of integration tests:

-await store.receive(
-  .login(
-    .twoFactor(
-      .presented(
-        .twoFactorResponse(
-          .success(AuthenticationResponse(token: "deadbeef", twoFactorRequired: false))
-        )
-      )
-    )
-  )
-) {
+await store.receive(\.login.twoFactor.twoFactorResponse.success) {

A TaskResult soft-deprecation

The TaskResult type was introduced in order to make it easier to conform a reducer's Action to Equatable, but given the streamlined TestStore.receive(\.action) API, actions no longer need to go through the ceremony of an Equatable conformance. As such, TaskResult has been soft-deprecated in favor of using the vanilla Result type that comes with Swift.

IdentifiedAction

The forEach operator on reducers and ForEachStore have been enhanced to work with a new dedicated action type called IdentifiedAction. This action type provides a wrapper for a child element action and identifier that pairs nicely with IdentifiedArray.

Migrating an existing forEach can take a few steps.

 struct State {
   var children: IdentifiedArrayOf<Child.State> = []
 }
 enum Action {
   // Update the parent action:
-  case children(id: Child.State.ID, action: Child.Action)
+  case children(IdentifiedActionOf<Child>)
 }
 var body: some ReducerOf<Self> {
   Reduce { state, action in
     switch action {
     …
     // Update the reducer if matching on the action:
-    case let .children(id, action):
+    case let .children(.element(id, action)):
       …
     }
   }
 }
 …
 // Update the view to a simpler scope:
-ForEachStore(store.scope(state: \.children, action: { .children(id: $0, action: $1) }) {
+ForEachStore(store.scope(state: \.children, action: { .children($0) }) {
 …
 // Update tests:
-await store.send(.elements(id: 0, action: .tap)) {
+await store.send(.elements(.element(id: 0, action: .tap))) {

Identified actions benefit from the new case key path syntax and so actions received by test stores can be described using a case paths that chains into the action via subscript:

await store.receive(\.elements[id: 0].response.success) { … }

Even more action case key path helpers

In addition to the new IdentifiedAction, the existing PresentationAction and StackAction types have been enhanced with case key paths that can be used when receiving test store actions:

 // Received presentation actions can omit the `presented` step:
-await store.receive(.destination(.presented(.tap)))
+await store.receive(\.destination.tap)

 // Received stack actions can chain into an ID subscript:
-await store.receive(.path(.element(id: 1, action: .tap)))
+await store.receive(\.path[id: 1].tap)

Trying the beta

These new tools are already available on the case-key-paths branch. If you are using an up-to-date version of the Composable Architecture you should be able to point to this branch and start giving things a try. The changes should be fully backwards-compatible, so let us know if pointing to the new branch causes any problems!

If you take things for a spin, please let us know (via Twitter, Mastodon, GitHub discussions, or our Slack community) if you have questions, comments, concerns, or suggestions!

[oliverfoggin]

[oliverfoggin]

I think I've done it. PR incoming.

[oliverfoggin]

PR added to swift-case-paths pointing to case-key-paths branch... pointfreeco/swift-case-paths#122

[tgrapperon]

After simply switching to case-key-paths, one feature we have with a rather large amount (7) of .forEach is now unable to build it in a reasonable time. Sectioning them on a couple of EmptyReducer at the top of body allows to build again. Likely a side effect of the new overloads.

[mbrandonw]

Yeah that's a bummer. If you have the time I would be curious if you could point your project to a fork of TCA where you delete the 3 deprecated forEach operators, and see if it improves things.

If it does, then it does mean at least when we release 2.0 things will get better.

[tgrapperon]

Yes, deleting only the first deprecated CasePath forEach allows to get through.

[stephencelis]

@tgrapperon I'm guessing not, but I wonder if application of @_disfavoredOverload helps at all?