AsyncSequence for the Effects system?

[oliverepper]

Hi all!

From watching the first sessions about swift concurrency I asked myself if Combine couldn't be replaced with AsyncSequences in the effects system. From my understanding AsyncSequences should be able do deliver everything that Combine Publishers do, even considering backpressure/demand handling. (not 100% sure, yet). Replacing Combine would free TCA from a closed source dependency and maybe opening up the possibility to be used on the other platforms that Swift can be deployed to.

[mbrandonw]

Hi @oliverepper, this is a really exciting topic for Swift and TCA, but unfortunately @stephencelis and I have both been traveling this week and haven't had much time to think through implications for the library. We have a foggy idea of making Store an actor and having effects become an AsyncSequence, but there are many details to think through and we want to consider radically different approaches that might be unlocked with all the new actor/async/await stuff.

But, I will say that we 100% agree with your idea that TCA would benefit greatly from losing its dependency on Combine, and we'd love to make that happen. There are some questions around effect cancellation, time based effects and schedulers, but we feel pretty confident they can either be solved or we can always allow Combine-style publishers for effects that can't be expressed purely with async/await.

[spadafiva]

I also immediately wondered what async/await would mean for TCA. This is really exciting to read and I'm excited about it. I just hope that whatever solution is followed will still allow folks that need to support iOS13 or until a solution (if any) for backporting is found.

[kielgillard]

I did wonder if async/await and structured concurrency might relax the need to return an effect if functions can await effects. This might reduce actions (say, from today's episode . getAnotherFactButtonTapped and . factResponse could be reduced to the former).

[coastjogger]

I tried to redefine Effect to use the signature: () async -> A? instead of combine.
Seems to work pretty well.

public struct Effect {
public let run: () async -> A?

public init(run: @escaping () async -> A?) {
    self.run = run
}

public func map<B>(_ f: @escaping (A) -> B) -> Effect<B> {
    Effect<B> {
        if let a = await self.run() {
            return f(a)
        }
        return nil
    }
}

}

[mbrandonw]

Yeah, that's definitely one way we can introduce concurrency into the library, but there's a few downsides to doing so.

First, by using only async functions we lose the ability to have effects emit multiple times, such as web sockets, timers, notifications, etc. Second, by adopting async directly before executors pan out we lose the ability to make asynchronous effects testable like we can with publishers and schedulers. And third, until "typed throws" shapes up in Swift there will be no concise way of describing an effect that can fail.

These are the biggest problems we are grappling with as we figure out how async fits into TCA. We've made some small steps in the past few months by introducing effect and view store helpers that interface with concurrency (see here). And there will be more to come as we figure out how we want to fully support concurrency. It will most likely come in multiple phases, with one phase that supports both async/await and Combine publishers, and then a future phase where we drop publishers entirely in favor of native Swift tools.

[mRs-]

Yeah I'm really concerned about typed throws in general and it seems that's currently not even on the agenda of Swift. Maybe this is something that will be not being a thing? Do you and @stephencelis know more about the plans in the current space of apple? I'm a huge fan of how the typed throws work in combine and it would be such a PITA to lose this completely...

[JacksonUtsch]

Seems like Swift in its current state is constraining progress in these areas. (In contrast in seems like TCA is revealing many areas where Swift lacks depth). To use AsyncSequence instead of a type-erased version requires type constraints (generics) on existential types or an equivalent. Case paths for enums is another. Typed throws could make error propagation nicer. Along with using EnvironmentObject-like clients demonstrated in the proto branch, this new Reducer API could then look something like:

let reducer: (State, Action) throws Failure -> any AsyncSequence where Output == Action

Not exactly sure how the reducer client requirements come into play, I believe they are EnvironmentKey-like and are used only in implementation. We'll need to use of a test scheduler equivalent, not sure of the async Clock, Timer or whatever it is.

Would be good to have a pre-release TCA with testing new API designs such as the AsyncSequence Effects but then again round about solutions I find quite annoying.

Here's a thread on throwing types https://forums.swift.org/t/precise-error-typing-in-swift/52045

[stephencelis]

@JacksonUtsch @mRs- We're working on some async/await improvements to TCA that will hopefully roll out soon once we work the kinks out. We also have an idea of how to make working with untyped errors a bit nicer.

We're still blocked by many compiler things before we could even begin to explore reducers that return AsyncSequences directly, but we also think maybe that's OK with what we have planned 😄