RFC: General tips and tricks #1666
Replies: 26 comments 50 replies
|
Try to make your |
|
I'm unsure about making |
|
I agree that |
|
Will we get compiler warnings / errors if we fail to use Sendable correctly? |
|
@tgrapperon I have never made any of my |
|
Avoid mutating property observers like |
|
I love property observer but it's definitely true that they aren't great when used in State, especially as said with wrappers. |
|
Name your actions according to their source rather than their expected effect. For example, you should probably use |
|
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. |
|
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. |
|
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. |
|
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?) |
|
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 |
|
When composing domains, name your state properties and embedded actions similarly. If you embed the |
|
Use the |
|
Likely a matter of taste, but name your features/domains directly when possible, without a |
|
If you're using a template to bootstrap your feature's views, add a simple |
|
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 |
|
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. |
|
We can probably also compile a list of known Apple bugs particularly visible when using TCA, like |
I'm not sure I know this one. What's this about? |
|
Private/nested empty enums used as |
this would be great. There's quite a bit of them... |
|
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 |
I'm not sure what this means. Can you provide examples? |
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 |
|
I'm guilty of this, good catch! |
|
Yeah, I think the key is "if your view doesn't touch store data or actions, you probably don't need it" |
|
Does this still work? Every time I try this approach I get a compiler error |
|
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. |
|
This one is rather unfortunate and may hopefully fix itself in a next version of Xcode: When implementing |
|
WOW!!! That's why code completion wasn't working!!! It's a lifesaver indeed :D |
|
Yeah this is a great tip! I didn't realize it was that easy. I've been moving stuff to a |
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. |
|
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 |
|
@tgrapperon I tried the |
|
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 |
|
I think this is more of a general Xcode / build targets / SPM tip and not specifically TCA related. |
|
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. |
|
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: |
|
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.
|
|
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. |
|
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 |
|
When |
|
Yeah that can be annoying. Luckily in TCA 1.0 we will be dropping the Combine version of |
|
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 |
|
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
} |
|
When reusing a Reducer at multiple places at the same time and using a .watch-function that you make |
|
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! |
|
Good to know, thanks for the heads up! Hopefully this will work together with ReducerReader. |
|
@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 ❤️ |
|
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. |
|
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()
} |
|
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: 
|
|
Good tip ! |
|
You can use |
|
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) |
|
@stephencelis actually...should I delete this? I just remembered that |
|
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. |
|
Addendum to cancellation: The same values used in |
|
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.😀 |
|
Now be careful not to be sherlocked as @mbrandonw said on the slack that they are working on macros :p |
|
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. |
|
Indeed that was just for the joke |
|
We have a very experimental macro on a swift-dependencies branch here: pointfreeco/swift-dependencies@main...macros |
|
@stephencelis Thank you for sharing the URL of the branch. Very awesome 👍 |
|
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 😄
|
|
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:
|
and others
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions