Announcement: Concurrency Beta

[stephencelis]

Hey everyone! As we kick off our series of episodes on "Async Composable Architecture," we'd like to invite users of the library to test our upcoming release more formally. We’ve been working on these tools for many, many, many months, and are excited that they are finally coming together! We hope to gather community feedback to make them even better for release.

The episodes will dive deep into the motivation and basic implementations of many new async features, but we'll do our best to give an overview of the additions and changes below. Most of these changes should be fully backwards-compatible, with a few minor exceptions. All deprecations are "soft" for now and should not produce noisy warnings.

Changes to reducer effects

The Effect type has been tightly coupled to the Combine framework for a long time now: it conforms to Publisher and we have expected library users to interact with it as such. While Combine suited us when TCA first launched, it is a complex framework that SwiftUI mostly hides behind the scenes, and is a learning hurdle for library users. It is also closed-source, which prevents TCA from being used on non-Apple platforms.

In our upcoming release we will begin to loosen our dependence on Combine by nudging library users toward a smaller collection of async/await endpoints on the Effect type. We believe that it is possible to define all of your application's effects in terms of these endpoints, and you can even completely avoid interacting with Effect as a Combine publisher. In the future, we hope to deprecate our dependency on Combine entirely and instead just offer the following surface area:

Effect.none

This endpoint is not new, and will remain the effect that does nothing.

Effect.task

This endpoint allows you to spin up an async context that will feed an action back into a reducer as some later date.

case .delayButtonTapped:
  return .task {
    try await Task.sleep(duration: NSEC_PER_SEC)
    return .delayResponse
  }

While Effect.task was introduced awhile ago, we’ve made a few changes.

Previously, we documented that you should not use Effect.task directly in your reducers, as the async context made testing precarious. This is no longer the case, as we have improved our scheduling and testing tools to accommodate async/await (see "Changes to the test store" and "Changes to Combine Schedulers").

Effect.task was also originally overloaded with throwing and non-throwing versions:

static func task(operation: () async        -> Action) -> Effect<Action, Never>
static func task(operation: () async throws -> Action) -> Effect<Action, Error>

We have consolidated this into a single endpoint that returns a non-failing Effect<_, Never> that uses an optional "catch" block for handling errors:

static func task(
  operation: () async throws -> Action,
  catch: ((Error) -> Action)? = nil
) -> Effect<Action, Never>

• If operation throws a CancellationError, the effect will be ignored and no action will be fed back into the system.
• If operation throws anything else, catch will be invoked to feed an error handling action back into the system.
• If catch is not provided, a runtime warning / test failure will be generated.

For more on error-handling ergonomics and Effect.task, see "Task results".

The version of Effect.task that returns Effect<_, Error> has been soft-deprecated, as it requires you to perform additional work with Combine operators to catch errors.

Effect.run

This is a new endpoint (not to be confused with the existing, Combine-friendly API). Like Effect.task, it allows you to spin up an async context, but instead of returning a single action to be fed back into the reducer, it can feed multiple actions back into the reducer over time via a send continuation.

case .startTimerButtonTapped:
  return .run { send in
    while true {
      try await Task.sleep(duration: NSEC_PER_SEC)
      await send(.timerTicked)
    }
  }

The send parameter, like ViewStore.send, accepts an optional animation parameter for performing SwiftUI animations:

await send(.timerTicked, animation: .default)

Error handling is done the same way as Effect.task: throwing a CancellationError will terminate the async work, while throwing anything else must be handled in a catch closure to avoid runtime warnings and test failures.

.run { send in
  try await send(.currentUserResponse(environment.apiClient.fetchCurrentUser()))
} catch: { error, send in
  send(.currentUserRequestFailed)
}

Effect.fireAndForget

This endpoint allows you to spin up an async context that will never feed an action back into the reducer.

return .fireAndForget {
  await environment.trackEvent(.tappedWelcome)
}

While a synchronous version of this endpoint has existed for a long time, the async-friendly version was introduced just recently.

Unlike Effect.task and Effect.run, errors are ignored, and the context will terminate as soon as one is thrown.

Effect cancellation

Effect cancellation remains mostly the same, with a few improvements.

First, ViewStore.send now returns a task that can be awaited/cancelled directly, this can help eliminate extra work done in the reducer to manage cancellation. (See "Changes to the view store" for more.)

Second, there are new async-friendly Task.cancel(id:) and withTaskCancellation(id:) helpers for introducing more fine-grained cancellation to an effect:

return .run { send in
  try await withTaskCancellation(id: ProfileRequestID.self) {
    // Make profile request
  }
  try await withTaskCancellation(id: TimelineRequestID.self) {
    // Make timeline request
  } 
}

Task results

We’ve introduced a new type, TaskResult to aid in performing failable work in the Composable Architecture. It can be used to wrap the output of an effect:

enum TimelineAction {
  case refresh
  case refreshResponse(TaskResult<[Post]>)
}
    
// In the reducer:
case .refresh:
  return .task {
    await .refreshResponse(TaskResult { try await environment.fetchTimeline() })
  }

So why use a TaskResult instead of a Result?

Swift error handling is currently untyped, which means an error thrown from an async effect is an any Error. TCA’s testing tools require a feature’s state and actions be equatable for assertions to be made, so modeling an effect response with Result is incompatible with these tools.

enum TimelineAction: Equatable { // 🛑
  case refresh
  case refreshResponse(Result<[Post], Error>) // any Error is not Equatable
}

🛑 Type 'TimelineAction' does not conform to protocol 'Equatable'

It has been common to dance around this by replacing errors with custom equatable error types, instead, but this requires a lot of boilerplate. TaskResult eliminates that extra work.

If you attempt to assert against a task result failure with a non-equatable error, the test will fail. Simply conform the error type you test to Equatable to get a passing test.

Changes to the view store

ViewStore.send now returns a ViewStoreTask, which is a handle to the lifecycle of any effects the reducer returns for the action.

This task can be awaited or cancelled, which means a SwiftUI view can use a task view modifier to automatically cancel and tear down long-living effects spun up by the reducer:

// In the reducer:
case onAppear:
  return .run { send in
    while true {
      try await Task.sleep(nanoseconds: NSEC_PER_SEC)
      send(.timerTick)
    }
  }
    
// In the view:
.task { await viewStore.send(.onAppear).finish() }

This makes it much easier for child features to clean up their long-living effects automatically, and will help avoid runtime warnings commonly encountered when using optional and forEach reducers.

Note: This change is generally source-compatible, as the task is marked with @discardableResult, but there is a potential source breaking change when called in the context of a continuation, like SwiftUI's withAnimation:

Button("Animate me") {
  withAnimation { // 🛑
    viewStore.send(.animateMeTapped)
  }
}

🛑 Conflicting arguments to generic parameter 'Result' ('Void' vs. 'ViewStoreTask')

The solution is to explicitly ignore the return value:

Button("Animate me") {
  _ = withAnimation {
    viewStore.send(.animateMeTapped)
  }
}

Or, in this case, use the animation parameter on ViewStore.send:

Button("Animate me") {
  viewStore.send(.animateMeTapped, animation: .default)
}

Changes to the test store

In order to test a reducer that uses async effects, the test store must be made more async-aware. There are two main changes to be aware of:

Async TestStore.receive

TestStore.receive has a new async overload, which will await the action to be received from an effect to give the concurrency runtime enough time to deliver the action.

store.send(.refresh)

await store.receive(.profileResponse("This is Blob's profile!")) {
  $0.profile = "This is Blob's profile!"
} 

The non-async version of receive has been soft-deprecated.

TestStoreTask

Where ViewStore.send returns a ViewStoreTask that can be cancelled/awaited, TestStore.send now returns a TestStoreTask that can do the same. This means if you write a test that spins up a long-living effect for a view’s task modifier, you can test its cancellation:

let task = store.send(.onAppear)

// Test long-living effects over time

await task.cancel()  // Tear down effects to complete the test

You can also wait for a test store task to finish before making an assertion:

let task = store.send(.timerStartButtonTapped)
    
store.send(.timerStopButtonTapped)
    
await task.finish()  // Allow task to complete

Changes to Combine Schedulers

TCA has heavily relied on our Combine Scheduler library to make time-based features more testable. While Swift 5.7 introduces the Clock protocol and paves a way towards writing time-based features without Combine, we will still benefit from improved tooling in the meantime.

As such, we’ve introduced the following changes to Combine Schedulers:

Async TestScheduler.advance

TestScheduler.advance has a new async overload for async contexts. It automatically suspends its task as it advances and schedules work to be performed.

Scheduler.sleep and Scheduler.timer

There are new async endpoints on Scheduler for sleeping a task or spinning up a timer. Use these endpoints inside Effect.task and Effect.run to schedule work and remain synchronously testable:

return .task {
  try await environment.mainQueue.sleep(for: .seconds(1))
  return .delayedResponse
}

return .run { send in
  for await _ in environment.mainQueue.timer(interval: .seconds(1)) {
    send(.timerTicked)
  }
}

These methods can be thought of as replacements for the Effect.delay and Effect.timer endpoints.

Trying the beta

To give the beta a shot, update your SPM dependencies to point to the concurrency-beta branch:

.package(
  url: "https://github.com/pointfreeco/swift-composable-architecture",
  branch: "concurrency-beta"
),

This branch also includes updated demo applications using these APIs, so check them out if you're curious!

We hope these new tools make TCA more fun and easier to use than ever. If you take things for a spin, please let us know if you have any questions, comments, concerns, or suggestions!

[jshier]

In my testing it appears that the default timeout of one millisecond isn't enough for things like URLProtocol stubbed network requests using URLSession. Applying a 15 millisecond timeout is enough to fix the tests, but it would be nice to be able to set the value only once rather than for every test. Perhaps TestStore could have a configurable default timeout? An initialized or mutable property would be simplest.

[stephencelis]

This is a reasonable request, thanks for suggesting it! We've pushed a property to a branch that is forked off the concurrency-beta branch:

fffe858

Naming to be bikeshed, and also we should consider how Swift 5.7's Duration will play nicely in a forwards-compatible way.

We'll be merging this branch back to concurrency-beta regularly as we refine things, but don't want to have the concurrency-beta branch constantly churning.

[tgrapperon]

Effect(value: .action) is being soft-deprecated, and it is recommended to switch over .task { .action }. This last effect is slightly different because it needs to hop into the store's context and there is a short time interval during which the store will expose a new State to the ViewStore, right before the action from .task is processed. In the case of Effect(value: .action), the store's publisher has to wait for the second action to be processed before emitting to the ViewStore. As a consequence, the behavior can be slightly different. It shouldn't cause major issues, but it could probably break animations which are often observing state using onChange and are also relying on the stability of the View's identity.

The following Gist demonstrates that the phenomenon can be spotted by a ViewStore. A GameFeature has a state with two bindable fields (playerID and points), and a third property called description which is derived from the values of these two states. Whenever the bindings are changing, the reducer emits an Effect to update this description. The gist presents two cases: one where it emits Effect(value: .updateDescription), and one where it emits .task {.updateDescription}. Both features are pulled-back in a Root feature and you can check that in the case of .task, the ViewStore catches the state where the bindings are updated but the description isn't. It switches to the correct value very shortly after, but I can imagine even more contrived examples where it could fire unwanted tasks from SwiftUI. There are many ways to refactor this to avoid the issue, but the point was to make it happen!

So the idea is to discuss whether the problem lies in the Effect(value:)->.task recommendation, or if using Effect(value:) to forward calls is a bad practice if the purpose is only to avoid code duplication. There are other solutions, like using inner functions inside the reducer as building blocks:

Reducer { state, action, environment in
  func updateDescription(_ inout State) {…}
  switch action {
  case .binding: 
	updateDescription(&state)
    return .none
  case .updateDescription:
  	updateDescription(&state)
    return .none
  }
}

Hopefully, reducers as protocol could help formalizing this kind of lego construction, where we could imagine ultra-specialized Reducers components of larger Reducers, processing only one kind of information/action.

Another standard example of action forwarding is for dismissing some presented modal whenever the user selects a value: you can either set the state's modal properties/flag to nil/false in the didSelect() action, or you forward to another action that handles the modal visibility. This case is functionally different from the previous one because we want to make sure that we're not missing other effects by simply setting the modal's state to nil/false

This issue wasn't really expressing until now, but if one starts to use more and more .task instead of Effect(value:), it is maybe desirable to clarify the situation and find some kind of general rule to decide if we should forward to another action, or if we should inline its corresponding effects.

It also poses the question of the necessity or not to have synchronous Effects (or atomic in some sense).

[stephencelis]

Good observation, @tgrapperon! Effect.task { .action } and Effect(value: .action) are indeed subtly different, but we believe treating all effects more equally is a positive change, and maybe will even steer folks away from adopting the pattern of using synchronous actions for code reuse and organization.

This is perhaps a gap in TCA's documentation that can be filled in a "Best Practices" article, but we believe a domain's actions should largely be limited to:

• User actions that come from the view (including view lifecycle actions)
• Effect results that feed data back to the store

And occasionally, depending on the domain, should it need to explicitly communicate to a parent:

• "Delegate" actions that the child domain emits to notify a parent that something in its domain has changed

Introducing actions for the sole purpose of code reuse or organization goes against the grain of this advice. It adds cases to the actions of a domain that are akin to goto/jump, which should probably never be sent to the store outside of the reducer's switch statement.

So we think it's better to treat effects more "honestly" as side effects. That means if you do return an action through a task:

return .task { .action }

It should be expected that this action comes from the outside world. This means effect animation is more predictably attached to the effect itself, instead of sometimes coming from the view, several steps removed:

return .task { .action }.animation()

Your solution of using a helper function (either locally in the reducer, fileprivate, or even defined as a mutable func on the reducer's state) is the way to go. We agree that there are some ergonomic rough edges with these helpers, but believe our exploration of reducer protocol conformances provides a natural, ergonomic place for helper code as instance methods.

We're definitely open to discussing whether truly synchronous effects should have a future in TCA, and we know some folks rely on it currently, especially those still on UIKit, where view store publishers emit more frequently than the SwiftUI runtime evaluates state, and we probably won't harden this deprecation till these details have been worked out.

[tgrapperon]

Thanks for the feedback @stephencelis! This is a really interesting take. It also means that our domain shouldn't rely on effects for our state to be in "good shape". By backing changes into one action, we prohibit external reducers to influence the process and potentially break things. The "dismiss modal on selection" was simply simulating/automating a user request to close the modal once they selected something, so it gets a pass.

So if we include "Domain embedding" into the list of possible actions, we can come up with the "DUDE" acronym to remember the list! Joking aside, I'll experiment to check what formalizing this would offer. For example, if all user actions were gathered into their own domain, we can easily imagine how we can disable all user actions by simply filtering what this reducer sees (and maybe even generically with a higher-order reducer). In the same idea, we could bypass all .delegate (or .callback) actions in one case switch. Same with .embedded, where we can carpet-bomb all .embed actions to .none while still being able to cherry-pick one .embedded(.child(.action) in the switch upstream for contextual effects. There are probably other interesting patterns that can emerge.

[rhys-rant]

Just spotted this discussion. Very interesting, and would be good and useful to have in some sort of "Best Practices" documentation!

@tgrapperon - when you say "it gets a pass" for your "dismiss modal on selection" action, does that mean you wouldn't move that action out to a helper function?

Say I have an action that presents a modal, and this can either be triggered directly by the user, or as the result of some other effect

Should I push the state mutation out to a mutable method on state, and simply call it from the .presentModal action and separately in whichever actions would ultimately result in modal dismissal, or is it okay to return Effect(value: .presentModal)/Effect.task { .presentModal } from those actions?

e.g. is this:

extension MyState {
  mutating func presentModal() {
    modalPresented = true
  }
}

// Reducer

case .apiUpdate(.success(let someData)):
  state.data = someData
  state.presentModal()
  return .none

case .presentModal:
  state.presentModal()
  return .none

considered preferable to this:

case .apiUpdate(.success(let someData)):
  state.data = someData
  return .task { .presentModal } // or return Effect(value: .presentModal) ???

case .presentModal:
  state.modalPresented = true
  return .none

even in cases where there might be a button that sends .presentModal?

[tgrapperon]

You can probably do both depending on the context. In this specific case, you're concatenating two actions that exist independently. The presentModal action exists by itself and does all that's required to present a modal. If the model's soundness doesn't rely on this action to be executed (which is likely the case for presentation), you can probably safely reuse the action and send a .task { presentModal }. The slight difference with the function is that it'll will emit another action that will be itself reduced. This is something that the parent can intercept/filter, and you can thus defer behavioral decisions to another parent; or decide to bake/froze them if you want to force presentation by using functions. In terms of presentation/navigation, I would probably still use independent actions for these reasons (and also because they're very low frequency, so it's almost transparent in terms of performance). It will maybe even more "natural" to do so if the navigation/presentation story is formalized at some point in TCA (but it is also possible that property wrappers would be able to offer affordances to perform required changes without re-emitting in some case).

But that's my personal take, and internal functions will work as well. I simply feel that this very specific case doesn't require them.

Whats should be avoided are "internal function" actions that exist for the sole purpose of reusing code.

[mluisbrown]

@tgrapperon @stephencelis FYI: the "new" behaviour of Effect.task { .action } vs Effect(value: .action) is in fact how Effect(value: .action) used to work until release 0.20.0 where the agglomeration of synchronous state changes was done as a performance improvement:

Performance improvement/fix: a store publisher will only emit a single state change per synchronous Store.send and asynchronous effect received. This means synchronous effects (returned immediately from a reducer via Effect.init(value:)) will no longer result in extra publisher emissions. This is a breaking change if your application previously depended on each of these emissions. Workaround: use Publisher.receive(on:) to schedule these effects on the next run loop tick.

[twof]

Are yall open to Linux support in the beta? Will it be possible to get away with no reliance on Combine, or not quite yet? My use case is that I'm working on an iOS/macOS app, but I'd be able to run our unit test CI on Linux boxes if we no longer needed to use Combine, which would be 10x cheaper.

[mbrandonw]

Hi Alex, not yet unfortunately. The Effect type still holds onto a Combine publisher. A lot more work needs to be done to shed that dependency, though we are eyeing it once we clear out the next few big releases, such as concurrency, reducer protocols and navigation.

[twof]

Sounds good 🙂 Thanks a bunch for the work and the library!

[mluisbrown]

Even once Combine is removed completely from the Effect type, ViewStore will always need to depend on Combine as it needs to conform to the ObservableObject protocol so that SwiftUI can observe state changes via @ObservedObject.

However, it would be possible to make ViewStore compile on Linux by using #if canImport(Combine) to conditionally import Combine and also guard the calls to .send() on the ObservableObjectPublisher Publisher, as I have done in the ReactiveSwift TCA port here: https://github.com/trading-point/reactiveswift-composable-architecture/blob/master/Sources/ComposableArchitecture/ViewStore.swift#L68

[sbeitzel]

If one wanted to run this on Linux, there is the OpenCombine framework. A quick peek at the issues shows it's missing .merge and .throttle but I have used it in one of my own projects and can say that ObservableObject and @ObservedObject work just fine on Linux.

[mbrandonw]

Hey everyone, we just opened a draft PR (#1189) of our ongoing work bringing concurrency to the library. We will be making smaller, more focused PR's against that branch so that it is clear how we are evolving things for the next few weeks.

[tgrapperon]

In the current concurrency-updates branch, you propose an AsyncStream init that wraps any async sequence in a stream, and you present it like some kind of type erasure in the documentation.
This method is slightly different from proposing a dedicated AnyAsyncSequence wrapper because, as I'm understanding it, it starts enumerating the wrapped sequence immediately when you create the value and doesn't wait to be (or not) enumerated itself. As I'm getting it, it would mean that if 10 notifications are emitted before some feature starts to enumerate over this stream in a .run for example, the 10 notifications will be delivered immediately. It is very likely that consumers will pop a stream out of the environment at the moment they want to iterate over it though, so it may not be an issue, but I can see people looking for erasure using it out of this context.
Am I understanding it correcly?

[stephencelis]

@tgrapperon We're definitely open to alternatives here, but AsyncStream seemed the lightest-weight solution to the problem of providing controllable async sequences from the environment. It's a construct that ships with the standard library that is easy to use, though there are definitely a few gotchas to be aware of:

First off, it's only appropriate to store these streams in your environment from endpoints that return new streams. E.g.:

// ❌ Not like this:
var notifications: AsyncStream<Event>

// ✅ Like this:
var notifications: @Sendable () -> AsyncStream<Event>

Async streams, when cancelled/terminated, are done for good, so if a feature tears down a stream, it should be a stream that it "owns" and freshly provisioned from a closure. Because of this, you're likely to only ever invoke notifications() right at the moment of iteration:

for await notification in environment.notifications() {
  await send(.action(notification))
}

As I'm getting it, it would mean that if 10 notifications are emitted before some feature starts to enumerate over this stream in a .run for example, the 10 notifications will be delivered immediately.

While this is the default, it typically shouldn't be a problem given the delayed provisioning use of for await event in environment.dependency(). If for some reason you do decide to provision a stream early, you could specify the stream's buffering policy to only emit the latest element.

Another issue with streams is that a single instance can't be iterated over by multiple subscribers. So if you have multiple features that need to iterate over the same stream, this can introduce a problem. So long as each of these features provisions a fresh stream from the live implementation/closure, things should behave as one expects in production, but if you write an integration test between such features, you can't simply inject a single controlled stream, as it can't be subscribed to by each feature. We've experimented with some workarounds, but at this point it might be better to reach for a different kind of async sequence that can be controlled, or in this case maybe wrap the stream in some kind of "shared" sequence.

This is all to say that adopting AsyncStream as a way of controlling an async sequence definitely comes with some caveats, but we hope to document them, and we also hope that the language and frameworks will fill in some of these issues with better solutions in the future. We're open to be convinced of otherwise, though, if you think there's a better default the library can provide.

[tgrapperon]

Thanks for the feedback @stephencelis!

if you think there's a better default the library can provide.

To my knowledge, there isn't, and I agree with the simplicity of reusing AsyncStream which is a very "friendly" async sequence. There is no standard shared sequence to my knowledge neither, but relying on a function that returns an AsyncStream already prevents many issues. When sharing is inevitable, I'm personally using a class or actor that vends a new stream on request over the same base sequence. It can be tricky with actors because you could end up easily with a () async -> AsyncStream, but I have a wrapper that allows returning synchronously an AsyncSequence that coalesces the awaiting with the first emission. My actors/classes are usually workers and sources of the events themselves. I'll check if I can generalize to wrap any async sequence instead.

My concern was about potential misuses, but I guess that the documentation can prevent many of them with appropriate warnings/notes.

[jshier]

I believe AsyncChannel from swift-async-algorithms is meant to fill the "reusable async stream" niche. Given the other dependencies on swift-* libraries, it seems fine to add another for this one as well if AsyncChannel does what's necessary.

[stephencelis]

@tgrapperon Thanks for sharing your explorations! If you have any code pushed demonstrating some of the patterns you've been using, would love to see.

@jshier Unfortunately we've found that current Async Algorithms releases are not quite production-ready yet, and that AsyncChannel as designed makes it very easy for your tests to get stuck waiting forever. I'm also not sure async channels are shareable.

Till the library has matured and we've had a chance to better vet the sequences it vends for testing, and close any usability gaps, we're not sure it's appropriate to bring it into TCA proper. Definitely open to revisit in the future, though.

[manmal]

AsyncChannel suspends the value sender until the value has been received on the other side of the channel (back pressure). One could work around this by wrapping the sending in a Task, but then the insertion order is not deterministic (Tasks race each other). I also doubt that AsyncChannel is shareable - my (albeit limited) experience has been that receivers just race each other for the next value.

[tgrapperon]

In some reducer, I'm updating some CoreData store using a func update(value: Value) async throws -> Void of my CoreData abstraction. While the user edits some field, I'm sending a .task {}.throttle(…). In the task, I would like to use the convenience of TaskResult<Void> to wrap my call. I don't really care about the result, but I would like to know if it failed. But right now, TaskResult is Equatable when its Success is Equatable and using Void breaks automatic Equatable conformance of my Action.

Should TaskResult<Void> be made Equatable, or is it a code-smell that another approach is desirable? I'm aware that Result<Void, some EquatableError> isn't Equatable, but the alternatives would force me back in the "Error aren't Equatable" situation that motivated TaskResult's introduction. Of course, I could easily map the result to some Equatable like Bool instead, but it wouldn't make a lot of sense in terms of action's payload signature. This is likely what I'll do however.

I can understand why it could matter in terms of future-proofing in any case Swift gets typed throws and the library goes back to Result where we would lose equatability again for Void successes. Is it the only motivation, or am I missing something? This is not a showstopper, but since I'm going to update a lot of things, I would like to get it right!

[stephencelis]

Should TaskResult<Void> be made Equatable, or is it a code-smell that another approach is desirable? I'm aware that Result<Void, some EquatableError> isn't Equatable, but the alternatives would force me back in the "Error aren't Equatable" situation that motivated TaskResult's introduction. Of course, I could easily map the result to some Equatable like Bool instead, but it wouldn't make a lot of sense in terms of action's payload signature. This is likely what I'll do however.

Good questions, @tgrapperon!

Earlier we experimented with some extra flavors of TaskResult, including one with an EquatableVoid, and even a typealias TaskFailure = TaskResult<Never>, but we decided to remove these helpers for the time being. While they "make sense" from a modeling perspective, we weren't sure the benefit outweighed the additional library surface area and documentation.

In the case of a void "result" that needs to feed back into the system, we think it's probably OK to push the decision onto the library user, either by adopting their own reusable EquatableVoid type and helpers, or by introducing more ad hoc equatable types per domain that needs to model a "void" success:

enum FeatureAction: Equatable {
  …
  case fooClientResponse(TaskResult<FooClientResponse>)
  
  enum FooClientResponse { case finished }
}

…
return .task {
  await .fooClientResponse(
     TaskResult {
       try await environment.fooClient()
       return .finished
     }
  )
}

We're open to reexamining this, though, before or after the broader update.

[rzulkoski]

@stephencelis @tgrapperon Now that both the Concurrency and ReducerProtocol updates are in the wild, do you guys have any further insights into the best way to handle this situation? I'm leaning towards using EquatableVoid at the moment but would love to hear other solutions in light of the work accomplished in the last 3 months.

[stephencelis]

The "best" way would be for equatable tuples to finally land in Swift 😅. In lieu of that, EquatableVoid is probably the simple way to keep the modeling the same.

[rhysm94]

@stephencelis @tgrapperon Now that both the Concurrency and ReducerProtocol updates are in the wild, do you guys have any further insights into the best way to handle this situation? I'm leaning towards using EquatableVoid at the moment but would love to hear other solutions in light of the work accomplished in the last 3 months.

Can't speak for anyone else, but the way I handle Void-returning async functions in a task is to have two actions, and use the catch closure.

For example, say I have a database persistence async method: saveModel: @Sendable (DBModel) async throws -> Void
I'd have a couple of actions like this:

enum Action: Equatable {
  case databaseSuccess
  case databaseFailure(FeatureError)
}

where FeatureError is an Equatable error that carries any information useful to the failure. Alternatively, if you just care that it failed, not why, you could always remove that associated value entirely, and not worry about the domain-specific error.

Then, in my reducer, I handle it like this:

case .save:
  let model = DBModel() // presumably by constructing from State
  return .task {
    try await database.saveModel(model)
    return .databaseSuccess
  } catch: { error in
    .databaseFailure(FeatureError(error: error))
  }

Not sure if this is the best way to handle it, and of course it can lead to you needing to make your own Equatable error type, which might end up defeating the point. But you could use NSError instead if you wanted. Either way, it's how I've been handling async throws -> Void calls with .task!

[tgrapperon]

As I'm converting my project, I'm encountering many .onAppear/onDisappear that I'm replacing with .task.
The current approach consists in awaiting the result of sending an action via some ViewStore instance:

WithViewStore(store) { viewStore in 
  Text("Hello \(viewStore.name)!")
    .task { await viewStore.send(.task).finish() }
}

As this pattern happens a lot, I'm wondering if we could improve the situation with a little sugar. For example, as we know we'll need a ViewStore to send the action, we can propose a .task(action: Action) extension of WithViewStore Views that does this automatically. The code above then becomes:

WithViewStore(store) { viewStore in 
  Text("Hello \(viewStore.name)!")
}.task(action: .task)

I've also experimented with storeTask(_ action: Action) or task(_ action: Action), and I couldn't decide what was the best solution.
Another option could be to offer an additional argument to WithViewStore's initializer:

WithViewStore(store, task: .task) { viewStore in 
  Text("Hello \(viewStore.name)!")
}

Another approach could directly use store to create a dedicated stateless ViewStore for the task:

VStack {
  DetailView(store.scope(…))
}.task(store: store, action: .task)

Thus, we could call .task(store: store, action: .task) on any view, but also .task(action: .task) on WithViewStore.

If the "store" variant could be defined in third-party code, the WithViewStore specialization needs access to the internal viewStore of WithViewStore.

What do you think about this?

[stephencelis]

Fun idea! We'll have to try it out and see how we like it 😄

If the "store" variant could be defined in third-party code, the WithViewStore specialization needs access to the internal viewStore of WithViewStore.

I don't have time to try right now, but I imagine this helpers should be definable outside the library today, perhaps with a custom ViewModifier. Can you share the code that wasn't working with us?

[tgrapperon]

I have a branch with the experiments here.
The idea of the WithViewStore specialization was to conveniently write the task outside of it:

WithViewStore() {
 … 
}.task(action: .task)

But for this to work with one argument only, we need access to the ViewStore instance from WithViewStore, which is currently private and only exposed in the closure. There are of course many other possibilities. Using a ViewModifier like .storeTask(viewStore, .task) is indeed possible from within the closure. Using the environment or preferences to do this at distance seems excluded if we want to keep control over what's happening (in the sense that it happens, and only once).

The more I'm thinking about it, the more it cognitively looks like a Store thing rather than a ViewStore one. We could easily have several WithViewStore in play, whereas there's generally only one top-level Store. I don't think that the convenience of having a one-argument overload that works only on WithViewStore is worth it finally, and I would lean toward only one way of fluently triggering a .task action with .task(store: store, action: .task) (or .storeTask(store, .task)), and maybe a WithViewStore.init overload that accepts a task: Action? parameter (if it's not too much for the compiler). Both solutions are implementable out of the library.

[kamcma]

Does BindingAction need to be (can it be?) made explicitly Sendable? I suppose it's not getting an automatic conformance because it's holding on to the reference type PartialKeyPath?

Without it, adding a .binding(BindingAction<FeatureState>) case to a feature's action enum makes the whole thing not Sendable, and then you get warnings sending any action case from an Effect if you have -warn-concurrency enabled.

(Very possible I'm doing something wrong, in which case, disregard!)

[stephencelis]

@stephencelis As an aside, the concurrency-updates and concurrence-beta are not even building with this flag on1.

The issue will also likely present with Animation which are not Sendable as of today. If required, we can probably imagine to provide a Sendable representation if they're still not Sendable by the time Swift 6 is released.

This is a known problem. The "fix" for getting a general build is as "easy" as adding a few @MainActors to the ViewStore binding APIs, but we haven't prioritized making TCA play nicely with these diagnostics for a couple reasons:

1. We're not quite sure we trust all of the diagnostics yet, especially when it comes to frameworks (including SwiftUI) that may not be fully audited yet (Animation not being sendable, for example). We'd rather not introduce the wrong fixes for things that aren't even problems, so we've been monitoring the situation and will try again in the future.
2. We plan to make a few big changes to the library that will make it more concurrency-safe by default, so we don't think it's worth investing too much effort in making the existing design pass under these flags.

The main question is "Is making Actions Sendable something we should try to enforce right now?".

As they're the main messaging support of TCA, it seems inevitable that they will need to be Sendable at some point, but I think this is not mentioned yet in the documentation yet.

This is quite a strong requirement, and there will be cases where the only option would be to either mark the whole enum @unchecked Sendable, manually wrap non-sendable associated values2, or park the problematic cases into some inner enum Unchecked: @unchecked Sendable sub-action. This later approach would allow to minimize the unchecked surface, and it is maybe possible to formalize it into something convenient to use.

We think that the vast majority of actions will be sendable by default (just as the vast majority of actions can readily synthesize Equatable), but there is a tool shipping with the Concurrency Beta that makes this slightly easier called UncheckedSendable (based off an adapter type mentioned in a proposal). You can use this type to more surgically adapt a case that isn't sendable:

enum SpeechAction {
  …
  case response(UncheckedSendable<SpeechResult>)
}

In the future, as you mention, we may be able to apply the wrapper directly:

enum SpeechAction {
  …
  case response(@UncheckedSendable SpeechResult)
}

[tgrapperon]

(including SwiftUI) that may not be fully audited yet […]

Because of its @MainActor annotations, I was assuming it was, or at least that it will be for iOS 16, but I'm likely wrong then. Is there a way to know other than checking for the presence Sendable types? I was supposing that Animation wasn't Sendable because is was maybe a wrapper around CAAnimation, but after closer inspection, it seems to be a regular value type, and thus with little reasons to not be Sendable.

I'll start to make my Actions Sendable then!

[stephencelis]

@tgrapperon We can only guess, but we've seen more annotations show up over time, and kind of assume an annotation only means "partially audited" 🤷‍♂️

[stephencelis]

(We've also filed FB10691662 "Make SwiftUI.Color and SwiftUI.Animation conform to Sendable" if you'd like to dupe!)

[tgrapperon]

Done! FB10909115

[mbrandonw]

Hello everyone, today we have officially released 0.39.0 of the library which makes all of these async tools available in the library, and ends the beta period of this feature. Thanks to everyone that provided feedback and helped catch bugs!