Would it make sense for the reducer closure to be marked as @MainActor?

[danieleformichelli]

Hello 👋

Given the reducer usually runs on the main thread, would it make sense to make the reducer closure @MainActor, or at least have the possibility to chose whether it needs to be a @MainActor or not?

Right now you can't access other non-async @MainActors directly in the reducer code because you would need to await for it, but if the reducer itself would be a @MainActor it wouldn't need to await to access another @MainActor, right?

Thank you 🙏

[mbrandonw]

Hi @danyf90, it is true that currently reducers are only meant to be run on the main thread, but marking it explicitly as @MainActor would be a breaking change for everyone using the library. We are moving forward with concurrency changes slowly so that we can minimize breakage when updating to the newest version of the library. For example, all of the new concurrency tools we introduced in 0.39 are fully backwards compatible and did not require any changes to existing TCA applications.

So, someday in the future we could make reducers @MainActor. But, what we'd really like to do is provide an even deeper integration of the library with Swift concurrency. This may mean turning Store into an actor or non-main global actor, and making ViewStore into a @MainActor. This would be a huge breaking change, and so we need to time it correctly and roll it out slowly, but once we achieve that then reducers do not need to be made @MainActor, which would be nice.

As an aside, I'm curious what APIs you are using in the reducer that are marked as @MainActor. It's possible that those APIs should be interacted with in an effect anyway so that they are controllable during tests and previews, in which case you are provided an async context to await, such as in Effect.task/.run/.fireAndForget.

[fatbobman]

@Alex293 Yes, that's exactly what I'm worried about. I shouldn't assume that in the future the Reducer will necessarily run on the main thread. But since ViewStore can be guaranteed to run on the main thread, maybe I can perform operations in ViewState that require the participation of MainActor.

[Alex293]

Either way I wouldn't store NSManagedObject directly in state and listen and map those to structs.
I'm pretty your views won't update if only NSManaged objects are updated.

[fatbobman]

For efficiency reasons, I can't convert all query results into struct and put them into TCA's State. I only keep a reference to them in State. Each object is passed to a child Reducer via ForEachStore . And trigger the update state through a seed. It's working fine so far. But considering that Reducer may not be able to run on non-main thread in the future (my NSMangedObjects are obtained from viewContext), I am going to fire fault this process in viewState. There is currently no problem passing them in different threads as long as the data in the NSManagedObject properties is not read.

[gerfarfel]

I think that Core Data really is a good example of a use case where a guarantee of having the reducer run on the main thread (or at least on a known specified thread) could be very helpful. In the app I'm working on, I'd like to be able to update TCA state with data from my Core Data store synchronously in the reducer, with no thread hops. One reason for this is that it would make coordination with my undo manager (implemented via a higher-order reducer) much simpler, reducing the likelihood of bugs. (And btw, I don't store Core Data managed objects in my TCA state, so that's not the issue.) @mbrandonw, your reply to the original question implies that we shouldn't assume that we will be able to specify the reducer's thread in future versions of TCA. I'm finding that working with that assumption is making my code more complex (and probably more error-prone). I'm pretty sure that I would mark my reducers as @MainActor if I was confident that I would be able to continue to do that in future versions of TCA – but as things stand, I'm not.

[mbrandonw]

Hi @gerfarfel, it seems too early to make any strong guarantees of when/where reducers will run, especially with respect to Swift's concurrency tools. After all, there still isn't an officially accepted proposal for custom executors, which is pretty much a requirement for reasonably interacting with core data in an async context.

We are keeping our eye on all the various proposals to see how things are progressing, but we cannot make reducers or stores @MainActor right now because it would be a hugely breaking change. At the very least we do guarantee that stores are single threaded, so as long as you send all actions on the main thread then all reducers will also run on the main thread.