RFC: General tips and tricks #1666
Replies: 26 comments 50 replies
-
|
Try to make your |
Beta Was this translation helpful? Give feedback.
-
|
I'm unsure about making |
Beta Was this translation helpful? Give feedback.
-
|
I agree that |
Beta Was this translation helpful? Give feedback.
-
|
Will we get compiler warnings / errors if we fail to use Sendable correctly? |
Beta Was this translation helpful? Give feedback.
-
|
@tgrapperon I have never made any of my |
Beta Was this translation helpful? Give feedback.
-
|
@Jeehut Concurrency checks are still disabled by default on Swift 5.8 AFAIK, and you need to enable them with the |
Beta Was this translation helpful? Give feedback.
-
|
Avoid mutating property observers like |
Beta Was this translation helpful? Give feedback.
-
|
I love property observer but it's definitely true that they aren't great when used in State, especially as said with wrappers. |
Beta Was this translation helpful? Give feedback.
-
|
Name your actions according to their source rather than their expected effect. For example, you should probably use |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
There is however a special category of utility reducers where the imperative effect style is likely preferable. For example 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. |
Beta Was this translation helpful? Give feedback.
-
|
This suggestion urges us to call it by its aetiology instead of the system behaviour / transformation. I think that sometimes, rewording 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?) |
Beta Was this translation helpful? Give feedback.
-
|
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
On top of that, another common word I prevent from using is |
Beta Was this translation helpful? Give feedback.
-
|
When composing domains, name your state properties and embedded actions similarly. If you embed the |
Beta Was this translation helpful? Give feedback.
-
|
Use the |
Beta Was this translation helpful? Give feedback.
-
|
Likely a matter of taste, but name your features/domains directly when possible, without a |
Beta Was this translation helpful? Give feedback.
-
|
If you're using a template to bootstrap your feature's views, add a simple |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
We can probably also compile a list of known Apple bugs particularly visible when using TCA, like |
Beta Was this translation helpful? Give feedback.
-
I'm not sure I know this one. What's this about? |
Beta Was this translation helpful? Give feedback.
-
|
Private/nested empty enums used as |
Beta Was this translation helpful? Give feedback.
-
this would be great. There's quite a bit of them... |
Beta Was this translation helpful? Give feedback.
-
|
Something that may not be immediately clear to newcomers: you don't need a Furthermore, if your Button("Send") { ViewStore(store.stateless).send(.userDidTapButton) }Note: I'm using |
Beta Was this translation helpful? Give feedback.
-
I'm not sure what this means. Can you provide examples? |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
I'm guilty of this, good catch! |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I think the key is "if your view doesn't touch store data or actions, you probably don't need it" |
Beta Was this translation helpful? Give feedback.
-
|
Does this still work? Every time I try this approach I get a compiler error |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
This one is rather unfortunate and may hopefully fix itself in a next version of Xcode: When implementing |
Beta Was this translation helpful? Give feedback.
-
|
WOW!!! That's why code completion wasn't working!!! It's a lifesaver indeed :D |
Beta Was this translation helpful? Give feedback.
-
|
Yeah this is a great tip! I didn't realize it was that easy. I've been moving stuff to a |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 Render unto Caesar the things which are Caesar's, the |
Beta Was this translation helpful? Give feedback.
-
|
@tgrapperon I tried the |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
I think this is more of a general Xcode / build targets / SPM tip and not specifically TCA related. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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: 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: |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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#>()
))
}
}
#endiftcasyncreducer 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 |
Beta Was this translation helpful? Give feedback.
-
|
When |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that can be annoying. Luckily in TCA 1.0 we will be dropping the Combine version of |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 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
} |
Beta Was this translation helpful? Give feedback.
-
|
When reusing a Reducer at multiple places at the same time and using a .watch-function that you make |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
Good to know, thanks for the heads up! Hopefully this will work together with ReducerReader. |
Beta Was this translation helpful? Give feedback.
-
|
@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 ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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()
} |
Beta Was this translation helpful? Give feedback.
-
|
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 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: 
|
Beta Was this translation helpful? Give feedback.
-
|
Good tip ! |
Beta Was this translation helpful? Give feedback.
-
|
You can use |
Beta Was this translation helpful? Give feedback.
-
|
For the 2 developers in the world that use UIKit, utilize ViewState transforms, and are already removing 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) |
Beta Was this translation helpful? Give feedback.
-
|
@stephencelis actually...should I delete this? I just remembered that |
Beta Was this translation helpful? Give feedback.
-
|
In .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))
}
} // .onChangeThe solution is to assign 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. |
Beta Was this translation helpful? Give feedback.
-
|
Addendum to cancellation: The same values used in |
Beta Was this translation helpful? Give feedback.
-
|
I created a swift macro annotation that calls fatalError because it is tedious to rewrite the closure of Annotate your struct or class with 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 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.😀 |
Beta Was this translation helpful? Give feedback.
-
|
Now be careful not to be sherlocked as @mbrandonw said on the slack that they are working on macros :p |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed that was just for the joke |
Beta Was this translation helpful? Give feedback.
-
|
We have a very experimental macro on a swift-dependencies branch here: pointfreeco/swift-dependencies@main...macros |
Beta Was this translation helpful? Give feedback.
-
|
@stephencelis Thank you for sharing the URL of the branch. Very awesome 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if this is useful for anyone else but we're using the namespaced actions like And so we've started to use It's sort of like Using this it means that if you have any Also... using Xcode code folding it looks so nice 😄
|
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
and others
-
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.
Beta Was this translation helpful? Give feedback.
All reactions