RFC: General tips and tricks

[tgrapperon]

Hello everyone!
When using TCA, there are a few simple prescriptions that are not immediately obvious, but that could make your life easier in the long run.

I didn't think in depth about the question, but I'll post as individual comments a few tips that immediately come to my mind. I'll post using an imperative form, but these are only personal (and open) prescriptions, and not something absolute or mandatory.

Feel free to comment or add your finds if you spotted something interesting while building apps with TCA. Maybe we can build a more structured list at some point.

[tgrapperon]

Try to make your States and Actions Equatable for testability, and Sendable for concurrency when possible.
Equatable for the State is important for testability with TestStore, and not something that you should systematically use to build ViewStores observing the whole State though.
Sendable Actions is almost a requirement as soon as you want to use concurrency. Sendable State is less important, but always nice to have, as you can very easily need to onboard a State value into an Action payload.

[Alex293]

I'm unsure about making State and Action Equatable this is probability one the the reasons people observe too much state in ViewStore. What I do is add those conformances in tests when it's not much more trouble than putting it in the feature.

[tgrapperon]

I agree that Equatable State may invite you to observe it. There are probably workarounds. For example, we may formalize things with protocol and warn you when the State from ViewStore is the same from the State from the feature, excepted when you mark this State with a marker protocol that would say that's it's OK. This also gave me an idea that should work in many cases without user changes. I'll experiment with it later!

[JackYoustra]

Will we get compiler warnings / errors if we fail to use Sendable correctly?

[Jeehut]

@tgrapperon I have never made any of my State or Action types conform to Sendable, but yet I'm using concurrency in many places. How come I've never run into a problem? Can you point me to sample code or docs where I can read up why I should use Sendable everywhere and what effect this could have? Thanks for sharing your tips!

[tgrapperon]

@Jeehut Concurrency checks are still disabled by default on Swift 5.8 AFAIK, and you need to enable them with the -warn-concurrency (and -enable-actor-data-race-checks) flags. You can check SE-0337 for more information.

[tgrapperon]

Avoid mutating property observers like willSet and didSet in your State, as it makes testability more complex. If you send an action that updates a State property with a didSet that updates another property, this didSet will also be triggered when you describe your state using the assert closures of TestStore's send or receive.
The simpler workaround is probably to make your property private(set) and to define a setProperty() setter function, but there are other possibilities.

[Alex293]

I love property observer but it's definitely true that they aren't great when used in State, especially as said with wrappers.

[tgrapperon]

Name your actions according to their source rather than their expected effect. For example, you should probably use .userDidTapIncrementButton rather than .incrementCount, as the former allows you to add additional logic to the action while staying true to its name. It also allows you to produce the same semantical effect with subtle variations using different actions according to the sources: .userDidTapCancelButton, .userDidDismissSheet, etc.

[mbrandonw]

This style of naming is not only relevant to TCA. When we work in vanilla SwiftUI we name the methods of observable objects in the exact same way. That is, we do:

class FeatureModel: ObservableObject {
  func addButtonTapped() {
    …
  }
  func loadButtonTapped() {
    …
  }
}

Rather than:

class FeatureModel: ObservableObject {
  func addItem() {
    …
  }
  func saveItems() {
    …
  }
  func startTimer() {
    …
  }
}

We find the latter style leads to less clear code. Often it encourages people to call multiple methods in their view because there is one single method to encpasulate the logic:

Button {
  self.model.addItem()
  self.model.saveItems()
  self.model.startTimer()
  self.model.trackAnalytics()
} label: {
  …
}

Or, if the above isn't done, instead what happens is addItem starts doing a lot more than "add item" would have you believe. It starts becoming responsible for syncing data, tracking analytics, etc.

Further, in our experience, the majority of actions don't involve any shared logic or effects. They just have their own little custom logic, and that's fine. In that case, it seems most appropriate to name the action after what the user did rather than the logic/effects because you are never going to use that action in another way.

And so if that is true, what is the reasoning to name some actions after user actions, and then others after logic/effects executed? Does that not just create more confusion?

So, as of this moment, naming actions after what the user does rather than what the logic/effects should be executed is what we plan to recommend in the documentation. If someone wants to write up a detailed report of the alternative, we would happily link to it.

[mbrandonw]

Another benefit that comes to mind is testing. A test can be far clearer when written in a style that tells a story of the things the user did in the interface:

store.send(.refreshButtonTapped)
store.receive(.apiResponse)
store.send(.deleteButtonTapped)

When the actions are named after logic in the reducer, the test doesn't tell as strong of a story. And you have to be intimately knowledgable of the view in order to be sure that the script of actions you are sending even matches what actually happens in the view.

[tgrapperon]

There is however a special category of utility reducers where the imperative effect style is likely preferable. For example BindingReducer with its .set(\.$key, value), or the upcoming PresentationReducer or NavigationReducer with their .present(id:), etc.

So if a general "best practice" rule is specified, it will have to take at least this kind of reducers into account. These reducers are very specific and far from the norm though, especially from an end-user standpoint.

[plaukiu]

This suggestion urges us to call it by its aetiology instead of the system behaviour / transformation.

I think that sometimes, rewording action to trigger would express this suggestion more precisely. It maintains a neat separation of causative event (the triggering event) and its outcomes (state transition, corresponding binding updates, anything else that might branch off of this). Action is agnostic to this separation. Action can also mean a complex multitude. To me, it seems that the word Action is closer in its meaning to the opposite suggestion – the expected effects, abstracting away any details. Just a musing.

The dislike that some may feel might be because the display invades the model, i.e. we define the model behaviours by events external to it, rather than attach 'sensors' to the system which are then assigned to specific triggers.

But I believe the suggestion is good because our systems are usually not exhaustive in their behaviours. After all, we strive for systems that can be extensible. In addition, we intend to expose our systems to external interaction. (Programming to an interface?)
Also, outcomes of a trigger are often impossible to reduce into single terms. There's an irreducible multitude of effects that can only be expressed in multiple phrases. These phrases are already presented to us as code. The suggestion to use aetiology for naming is always consistent and reduces the cognitive load from getting into the habit of doing something that will prove impossible to achieve at some point.

[Jeehut]

I totally agree with this one, it's been the most frequent cause for issues in code bases I've taken over as it leads to misunderstandings over time. But I personally find the .userDid prefix to be unnecessary and even a bad smell for 2 reasons:

1. It's simply redundant when the user actually did that. We're in the UI domain here, most actions are done by the user.
2. It's sometimes wrong. Imagine I have a userDidTapButton action, but I want to call it programmatically. Should I define another action for that? Should I rename the action? What if I forget to? I prefer to leave the user out.

On top of that, another common word I prevent from using is clicked or tapped. They are platform-specific terms, clicking being native for the Desktop where a mouse is more common and tapped being native for touch interfaces such as on iPhone. I prefer using pressed (or press if you prefer that) which works on all platforms. Especially now that SwiftUI allows to copy over code between platforms so easily.

[tgrapperon]

When composing domains, name your state properties and embedded actions similarly. If you embed the Player domain into a larger one, using var currentPlayer: Player.State for the state, and case currentPlayer(Player.Action) make scoping more symmetrical and easier to think about.
I personally apply the same rule for ForEach compositions, even if the singular is often used for the Action: var players: IdentifiedArrayOf<Player.State> & case players(UUID, Player.Action) instead of case player(UUID, Player.Action). But this is a personal preference.

[tgrapperon]

Use the Of typealiases when possible, it makes a lot of things nicer/tidier! StoreOf<Reducer> == Store<Reducer.State, Reducer.Action>, ViewStoreOf, ReducerProtocolOf<Self>, etc. And if you embed a collection of Identifiable State into a parent feature, you also have the IdentifiedArrayOf<State>.

[tgrapperon]

Likely a matter of taste, but name your features/domains directly when possible, without a Reducer suffix: struct Player: ReducerProtocol instead of struct PlayerReducer: ReducerProtocol. Of course, this is not always possible. In this case, I'm personally using the Feature suffix: struct PlayerFeature: ReducerProtocol.
Similarly, you also probably don't need to use a State or Action suffix by default: var player: Player.State instead of var playerState: Player.State.
The only exception is the View that I often name [Feature]View.

[tgrapperon]

If you're using a template to bootstrap your feature's views, add a simple Action or A typealias to your View: typealias A = Feature.Action. This makes it easier to scope stores (as long as we don't have built-in case paths that can be completely inferred): store.scope(state: \.player, action: A.player) instead of store.scope(state: \.player, action: Feature.Action.player)

[tgrapperon]

As an alternative to the typealias, you can define:

public protocol StoreView: View {
  associatedtype S
  associatedtype A
  var store: Store<S, A> { get }
}

and conform to StoreView instead of View. S and A should then be inferred from your Store instance (it should also work when using StoreOf), and you can probably also use extensions to this protocol to host nice amenities.

[mbrandonw]

Great list! Especially this one. 😁

I think soon we will be able to get a document together with best practices, and this provides a great start. We could also add the view/internal/effect/delegate action cases a la @krzysztofzablocki's and @IanKeen's style.

[tgrapperon]

We can probably also compile a list of known Apple bugs particularly visible when using TCA, like TextField emitting twice, or private cancellation IDs being pruned in Release mode. Searching the issue/discussion for the "Apple Bug" tag is not very convenient, as there are many duplicates and the explanation/identification also often arrives later in the conversation.

[mbrandonw]

private cancellation IDs being pruned in Release mode

I'm not sure I know this one. What's this about?

[tgrapperon]

Private/nested empty enums used as IDs being sometimes wrongfully discarded in release builds. This was recently discussed in #1556. The workaround is apparently to make the enum's type public or(and?) less nested. In my case, it was only used in body's from a reducer and from a SwiftUI view, and defined as a private nested type of the reducer. Making it public fixed the issue.
EDIT: According to #1556, this doesn't only affect enums used as cancellation ID, but this is how I experienced it, and thus how I remembered it.

[adriansergheev]

We can probably also compile a list of known Apple bugs particularly visible when using TCA, like TextField emitting twice, or private cancellation IDs being pruned in Release mode. Searching the issue/discussion for the "Apple Bug" tag is not very convenient, as there are many duplicates and the explanation/identification also often arrives later in the conversation.

this would be great. There's quite a bit of them...

[tgrapperon]

Something that may not be immediately clear to newcomers: you don't need a ViewStore to scope a store. It is possible to compose a child feature without involving a ViewStore. It works the same for ForEachStore, IfLetStore, SwitchStore, etc. You only need a ViewStore to display domain specific (or "local") information and send back actions from this local domain to the store.

Furthermore, if your ViewStore is only used in a low-frequency context (like sending an action when pressing a Button) and not to display some information in the UI, you can create a ViewStore on the spot when you send the action:

Button("Send") { ViewStore(store.stateless).send(.userDidTapButton) }

Note: I'm using .stateless (that is a Store where the State is Void) to create a ViewStore without having to deal with the observe: argument.
I'm not saying that this approach is better. If you already have an observed ViewStore at hand, you should probably use it, but there is no need to create a WithViewStore to simply send an action. In this case, creating a ViewStore on the spot is probably more performant.

[jshier]

Something that may not be immediately clear to newcomers: you don't need a ViewStore to scope a store. It is possible to compose a child feature without involving a ViewStore. It works the same for ForEachStore, IfLetStore, SwitchStore, etc. You only need a ViewStore to display domain specific (or "local") information and send back actions from this local domain to the store.

I'm not sure what this means. Can you provide examples?

[tgrapperon]

struct TeamView: View {
  let store: StoreOf<Team>
  var body: some View {
    List {
	  Section {
        PlayerView(store: store.scope(state: \.bestPlayer, action: Action.bestPlayer))
      } header: {
        Text("Best player")
      }
	  Section {
        ForEachStore(store.scope(state: \.players, action: Action.players)) {
          PlayerView(store: $0)
        }
      } header: {
        Text("Team")
      }
    }
  }
}

No ViewStore is required to build this view (of course, there is one internal to ForEachStore, but this is an implementation detail). I've seen folks who were surprised that this would work, and who were introducing a (useless) top-level WithViewStore in this configuration.

[fabstu]

I'm guilty of this, good catch!

[JackYoustra]

Yeah, I think the key is "if your view doesn't touch store data or actions, you probably don't need it"

[Muhammed9991]

Does this still work? Every time I try this approach I get a compiler error

[mbrandonw]

I will add to this list that we should discuss how running tests in an application target can cause failures to leak out, as described in this discussion: #1652.

I don't know if there is something we can do at the library level, but it's annoying enough that we should get some documentation on it.

[tgrapperon]

This one is rather unfortunate and may hopefully fix itself in a next version of Xcode: When implementing Reduce { state, action in … } reducers in ReducerProtocol's body's, you may lose code completion for your action's cases as soon as there are a few reducers in body. You apparently can regain code completion for these cases if you explicitly specify the generics of your Reduce reducer: Reduce<State, Action> { state, action in … }.

[acosmicflamingo]

WOW!!! That's why code completion wasn't working!!! It's a lifesaver indeed :D

[mbrandonw]

Yeah this is a great tip! I didn't realize it was that easy. I've been moving stuff to a func core(state:action) in my reducer to regain autocompletion. We will definitely get a tips & tricks doc brewing soon. 🙂

[yuanhang]

Yeah this is a great tip! I didn't realize it was that easy. I've been moving stuff to a func core(state:action) in my reducer to regain autocompletion. We will definitely get a tips & tricks doc brewing soon. 🙂

It might related to the builder style makes the complier has a hard time figuring out the type. Before this, my "solution" is comment out the ScopeReducers/BindingReducers and leave only the Reduce {}, then comment it back.

[tgrapperon]

As I'm thinking about it, it is maybe possible to define a

extension ReducerProtocol {
  public typealias Core = Reduce<State, Action>
}

and this would probably allow to do just Core { state, action in … }. It would only work at the top level of your body, so that's why it likely shouldn't ship with the library, but it can save you a few keystrokes if you define it in your own projects (provided that it is indeed working).

Render unto Caesar the things which are Caesar's, the Reduce<State, Action> tip comes from @stephencelis!

[davdroman]

@tgrapperon I tried the Core approach but I'm afraid the compiler chokes regardless for large reducers. Same with Reduce<State, Action>. func core seems like the only reliable way.

[JackYoustra]

I'll shoot...

Should you be using a multi-module project, you have to define every library you use a preview in as a target in your Package.swift file. Additionally, in order to use the preview, you have to select the library for the target the current file belongs to as the current scheme in order for previews to avoid the "file not found as part of this module" error.

[andreyz]

I think this is more of a general Xcode / build targets / SPM tip and not specifically TCA related.

[JackYoustra]

You can use vscode for TCA - the SPM extension and xcode tools installation is enough to get pretty quality linking, especially with the multi-package setup.

The big benefit you get with vscode is github copilot: you can get amazing first approximations / boilerplate generation with the following steps:

First, do import preambles, top-level struct defintion, and state definition. Be very careful to name your variables exactly their abstract intent. From that (at least in my project), copilot can generate at least basic reducers and even a reasonable view implementation!

It can also generate great dependency definitions - again, define the protocol / struct first before touching any implementation / mocks.

[ibrahimkteish]

If you are using Sourcery Pro, I have made the bellow simple template.

When you want to implement a new Reducer, you need to just write its definition ie: public struct MyFeatureReducer: ReducerProtocol {} then put the cursor in the middle of the name and let Sourcery generate the rest for you. Remove the commented out line if you dont need them or uncomment them.

result:

public struct MyFeatureReducer: ReducerProtocol {
  // MARK: - State
  public struct State: Equatable {
    public var temp: String
    // @BindableState
    // public var tempBindable: String
  }
  
  // MARK: - Action
  public enum Action: Equatable /*, BindableAction*/ {
    case nada
    // case binding(BindingAction<State>)
  }
  
  // MARK: - Dependencies
  // @Dependency(\.apiClient) var apiClient
  
  // MARK: - Init
  public init() {}
  
  // MARK: - Body
  public var body: some ReducerProtocol<State, Action> {
    Reduce { state, action in
      switch action {
        case .nada:
          state.temp = ""
          return .none
          // case .binding:
          // return .none
      }
    }
  }
}

The template:

{% for type in types.structs %}

  // MARK: - State
  {{ type.accessLevel }} struct State: Equatable {
    {{ type.accessLevel }} var temp: String
    // @BindableState
    // {{ type.accessLevel }} var tempBindable: String
  }

  // MARK: - Action
  {{ type.accessLevel }} enum Action: Equatable /*, BindableAction*/ {
    case nada
    // case binding(BindingAction<State>) 
  }

  // MARK: - Dependencies
  // @Dependency(\.apiClient) var apiClient
  
  // MARK: - Init
  {{ type.accessLevel }} init() {}

  // MARK: - Body
  {{ type.accessLevel }} var body: some ReducerProtocol<State, Action> {
    Reduce { state, action in
      switch action {
        case .nada:
          state.temp = ""
          return .none
     // case .binding:
       // return .none
      }       
    }
  }

{% endfor %}

[mackoj]

Hi @ibrahimkteish,

Thanks for sharing your tip. I do like snippets and I hope we soon be able to have them in our project.

Snippets that I use when working with TCA.

[ibrahimkteish]

Thank you for your reply, This is amazing, I believe it would be good if you can share (if possible legally) your snippets with the rest of the community.

[mackoj]

You can add them to your Xcode by pasting them into Xcode then right click on them and select create code snippet.

tcaview

import ComposableArchitecture
import Foundation
import SwiftUI

public struct <#Reducer#>View: View {
  let store: StoreOf<<#Reducer#>>
  
  public init(store: StoreOf<<#Reducer#>>) {
    self.store = store
  }
  
  public var body: some View {
    WithViewStore(self.store, observe: <#ViewState#>) { viewStore in
      Text("View")
    }
  }
}

#if DEBUG
struct <#Reducer#>View_Previews: PreviewProvider {
  static var previews: some View {
    <#Reducer#>View(store: StoreOf<<#Reducer#>>(
      initialState: <#Reducer#>.State(),
      reducer: <#Reducer#>()
    ))
  }
}
#endif

tcasyncreducer

import ComposableArchitecture
import Foundation

public struct <#Reducer#>Sync: ReducerProtocol {
  public typealias State = <#SyncedWithReducer#>.State
  public typealias Action = <#SyncedWithReducer#>.Action
  
  public init() {}
  
  public var body: some ReducerProtocol<State, Action> {
    
    Reduce { state, action in
      switch action {
      }
    }
  }
}

tcareducer

import Foundation
import ComposableArchitecture

public struct <#Reducer#>: ReducerProtocol {
  public struct State: Equatable {
  }
  
  public enum Action: Equatable {
  }
  
  public init() {}
  
  public var body: some ReducerProtocol<State, Action> {
    
    Reduce(self.core)
  }
  
  func core(state: inout State, action: Action) -> EffectTask<Action> {
    <#ReducerCode#>
  }
}

tcaruncancel

Effect.run { send in
  do {
    try await withTaskCancellation(id: <#Hashable#>) {
      for try await response in <#AsyncThrowingStream#> {
        try Task.checkCancellation()
        await send(.<#Action#>)
       }
    }
  } catch {
    logger.critical("\(customDump(action))\n\(#file):\(#line)\n\(customDump(error))")
  }
}.receive(on: mainQueue).eraseToEffect()

tcarun

return Effect.run { send in
  do {
    let response = try await <#work#>
    await send(.<#action#>(response))
  } catch {
    logger.critical("\(customDump(action))\n\(#file):\(#line)\n\(customDump(error))")
  }
}

Hope it helps you out too

[fabstu]

When return .run { send in shows an error like Cannot pass function of type '(Send<Action>) async -> any Cancellable' to parameter expecting synchronous function type, add return .run { send async -> Void in and it shows where the build error is. Without the addition, XCode tries to use an old non-async .run-function and fails to show the actual error.

[mbrandonw]

Yeah that can be annoying. Luckily in TCA 1.0 we will be dropping the Combine version of .run and so it will not be a problem then!

[acosmicflamingo]

Looks like this might be the first linter-related comment on here :) I have found the following to be useful in my .swiftlint.yml:

custom_rules:
  tca_explicit_generics_reducer:
    included: ".*\\.swift"
    name: "Explicit Generics for Reducer"
    regex: 'Reduce\s+\{'
    message: "Use explicit generics in ReducerBuilder (Reduce<State, Action>) for successful autocompletion."
    severity: error

  tca_scope_unused_closure_parameter:
    name: "TCA Scope Unused Closure Parameter"
    regex: '\.scope\(\s*state\s*:\s*\{\s*\_'
    message: "Explicitly use closure parameter when scoping store (ensures the right state is being mutated)"
    severity: error

  xctassertnodifference_preferred:
    name: "XCTAssertNoDifference Preferred"
    regex: 'XCTAssertEqual\('
    message: "Use PointFree's XCTAssertNoDifference from CustomDump library when possible"
    severity: warning

[acosmicflamingo]

I don't know if I'm the only TCA Boundary user (TCA Action Boundaries by Krzysztof Zablocki, Thoughts on "Action Boundaries" Discussion) that has nested switch statements to group reducer actions, but I strongly advise that you don't do this. When your reducer gets large, it becomes SO hard to figure out whether the current case is for your X action or Y action. Flattening out the switch statements may mean you have a long case like case let .view(.foo(.bar(.hahahaha(.success(ohboy))))) but at least you know what the action is, no matter where in the reducer you are looking.

switch action {
-case let .view(viewAction):
-  switch viewAction {
-    case .didLoad:
-      return .run { send in
-        send(._internal(.loadSongs))
-      }
-  }
-case let ._internal(internalAction):
-  switch internalAction {
-    case .loadSongs:
-      state.songs = fetchSongs()
-      return .none
+case .view(.viewDidLoad):
+  return .run { send in
+    send(._internal(.loadSongs))
   }
+
+case ._internal(.loadSongs):
+  state.songs = fetchSongs()
+  return .none
}

[fabstu]

When reusing a Reducer at multiple places at the same time and using a .watch-function that you make .cancellable, then do not set cancelInFlight to true. When the second view appears and runs its .task{}, it cancels the first's .watch call automatically.

[mbrandonw]

This a good tip, but also we have some planned changes that will make it so that the same reducer used in different places will not trample on each other's effects like that. We've got a bit more experimentation to do but the initial results are promising!

[fabstu]

Good to know, thanks for the heads up! Hopefully this will work together with ReducerReader.

[chrisjrex]

@mbrandonw any progress on this? I ran into it this week and lost a few hours. Thanks to @ibrahimkteish for highlighting this tip & repo links to back it up ❤️

[mbrandonw]

No updates right now, and it will be more of a TCA 2.0 thing since it is a fundamental change to how the library works.

[acosmicflamingo]

If you're going to use protocols to ensure that your views conform to using TCA's stores and viewStores, make sure you do NOT name your associated types State and Action. I just spent the last 3 hours wondering why my UITextField subclass randomly did not conform to it, giving me a really random and stupid error. Turns out it's because UITextField is a subclass of UIControl, and the parent class is already utilizing the State namespace.

public protocol TCAStoreSupport: CombineSupport {
  associatedtype StoreState  // Should NOT be 'State'
  associatedtype StoreAction: TCAAction
  associatedtype ViewState

  var store: Store<StoreState, StoreAction> { get }
  var viewStore: ViewStore<ViewState, StoreAction.ViewAction> { get set }
  var cancellables: Set<AnyCancellable> { get set }

  func setupUI()
  func setupBindings()
  func setupActions()
}

[FredericRuaudel]

When you start to have big reducer's body with dozen of actions, it can start to be hard to navigate to or quickly find a specific action implementation. You can use Xcode breadcrumb menu associated with // MARK: comment to ease the process like this:

import ComposableArchitecture

public struct MyFeature: Reducer {
    public struct State { }
    
    public enum Action {
        case action1
        case action2
        case action3
        case action4
        case action5
        case action6
        case action7
    }
    
    public var body: some ReducerOf<Self> {
        Reduce<State, Action> { _, action in
            switch action {
            // MARK: - .action1
            case .action1:
                return .none
                
            // MARK: - .action2
            case .action2:
                return .none
                
            // MARK: - .action3
            case .action3:
                return .none
                
            // MARK: - .action4
            case .action4:
                return .none
                
            // MARK: - .action5
            case .action5:
                return .none
                
            // MARK: - .action6
            case .action6:
                return .none
                
            // MARK: - .action7
            case .action7:
                return .none
            }
        }
    }
}

Then, you'll get this in the breadcrumb of the file, click on any action name to be moved right to it in the switch:

[mackoj]

Good tip !

[Alex293]

You can use MARK: - REDUCER and then MARK: ActionX (without the dash) so the actions stay grouped and at the same level under reducer.

[acosmicflamingo]

For the 2 developers in the world that use UIKit, utilize ViewState transforms, and are already removing ViewStore from their UIKit apps, this little extension can remove some boilerplate code:

import Combine
import ComposableArchitecture
import Foundation

extension Store {
  public func transformState<ViewState>(
    to viewState: @escaping (_ state: State) -> ViewState
  ) -> Store<ViewState, Action> {
    scope(state: viewState, action: { $0 })
  }
}

Then all you need to do is just pass the ViewState initializer to it like this:

let viewStore = store.transformState(to: ViewState.init)

[acosmicflamingo]

@stephencelis actually...should I delete this? I just remembered that stateless and actionless were deprecated: https://github.com/pointfreeco/swift-composable-architecture/blob/main/Sources/ComposableArchitecture/Store.swift#L567. I don't want to post things that go against the vision you and Brandon have.

[fabstu]

In View.onChange when using viewStore.state inside and outside a DispatchQueue.main.async, viewStore.state value can change in-between. In my case, the wrong viewStore.state value was passed into store.send as a result.

.onChange(of: isActive) { newIsActive in

    Self.logger.log(
        """
            update_to_unset=\(String(describing: viewStore.state), privacy: .public)
        """
    )

    DispatchQueue.main.async {
        // If that is set, unset it.
        store.send(.unset(viewStore.state))
    }

}  // .onChange

The solution is to assign viewStore.state to a variable and use that inside the DispatchQueue.main.async call instead.

Note: This only happened under certain preconditions. This warning here is just so you are aware of the potential issue. In my case I first had to switch away from the tab and back again, only then the issue arose (semi-reproducabily). I also used state variables and view vanishing due to having been deleted (that triggered the state change and the .onChange here). I use the ReducerReader and my own instrumentation patch ontop TCA 1.0. But.. the debugging was painful.

[fabstu]

Addendum to cancellation: The same values used in .cancellable and in .cancel need to be besides the same value also be of the same type. One being an optional and the other not being an optional means the .cancel will be a no-op and so the .cancellable to not be cancelled despite both referring to the same Int value.

[yimajo]

I created a swift macro annotation that calls fatalError because it is tedious to rewrite the closure of testValue every time when the closure of the side effect object is changed.

Annotate your struct or class with @FatalTestValue.

import FatalTestValue

@FatalTestValue
struct Example {
    var create: @Sendable (Int) async throws -> Void
    var read: @Sendable (Int) async throws -> String
    var update: @Sendable (Int, String) async throws -> Void
    var delete: (Int) -> Void
}

This will automatically generate an extension with a testValue property.

extension Example {
    public static let testValue = Example(
        create: { _ in
            fatalError()
        },
        read: { _ in
            fatalError()
        },
        update: { _, _ in
            fatalError()
        },
        delete: { _ in
            fatalError()
        }
    )
}

https://github.com/CuriositySoftware/swift-fatal-test-value

It's fun to use swift macro to solve TCA's boilerplate.😀

[Alex293]

Now be careful not to be sherlocked as @mbrandonw said on the slack that they are working on macros :p

[yimajo]

If the TCA official can provide a swift macro, that would be a good thing. 😀

Because I want to make a lot of swift macro and this is just a practice for that.
Looking at macro code is a learning experience.

[Alex293]

Indeed that was just for the joke

[stephencelis]

We have a very experimental macro on a swift-dependencies branch here: pointfreeco/swift-dependencies@main...macros

[yimajo]

@stephencelis Thank you for sharing the URL of the branch. Very awesome 👍

[oliverfoggin]

I don't know if this is useful for anyone else but we're using the namespaced actions like .view .delegate etc...

And so we've started to use CombineReducers {...} alongside this...

import ComposableArchitecture

public struct NestedAction<State, Action, ChildAction>: Reducer {
	@usableFromInline
	let toChildAction: CasePath<Action, ChildAction>

	@usableFromInline
	let toEffect: (inout State, ChildAction) -> Effect<Action>

	@inlinable
	public init(
		_ action: CasePath<Action, ChildAction>,
		toEffect: @escaping (inout State, ChildAction) -> Effect<Action>
	) {
		self.init(toChildAction: action, toEffect: toEffect)
	}

	@usableFromInline
	init(
		toChildAction: CasePath<Action, ChildAction>,
		toEffect: @escaping (inout State, ChildAction) -> Effect<Action>
	) {
		self.toChildAction = toChildAction
		self.toEffect = toEffect
	}

	public func reduce(into state: inout State, action: Action) -> Effect<Action> {
		guard let childAction = self.toChildAction.extract(from: action) else {
			return .none
		}

		return toEffect(&state, childAction)
	}
}

It's sort of like Scope but returns Effects of the parent and so doesn't require a whole new Reducer etc... What it means is that we can define a single reducer like...

CombineReducers {
  NestedAction(/Action.view) { state, action in
    switch action {
    case .buttonTapped: // no need to prefix with `.view`
      return doSomething
    }
  }

  NestedAction(/Action.clientAction) { state, action in
    switch action {
    case .receivedData(let data): // no need to prefix with `.clientAction`
      state.data = data
      return .none
    }
  }
}

Using this it means that if you have any onChange logic you can apply it to the outer CombineReducers and any action that changes state will be caught.

Also... using Xcode code folding it looks so nice 😄

[IanKeen]

Larger TCA codebases can be hard to navigate especially if you have the same action coming from multiple places, you can use xcodes symbol search feature to find where a certain action is being used throughout your codebase: