How to design a dependency limited to a specific actor?

[romanatexn]

Context:
I'm using complete concurrency checking enabled and want to specify a dependency which is confined to the MainActor

`extension MyDependency: DependencyKey {

static var liveValue: MyDependency {
    
    let viewModel = DependencyClass()
    return MyDependency(
        create: viewModel.create,
        clear: viewModel.clear,
        process: viewModel.process,
        uiState: viewModel.uiState,
        navigation: viewModel.navigation
    )
}

Problem:
I receive the following warning:
Main actor-isolated static property 'liveValue' cannot be used to satisfy nonisolated protocol requirement

Which is completely logical, but I don't know how to work around this warning.
Any ideas?

Thanks!

[mbrandonw]

Hi @romanatexn, typically one does not make the dependency itself an actor, main or otherwise, and instead one uses an actor under the hood of the dependency to power it. If you can provide a very simple, concrete example of a @MainActor dependency you are trying to register with the library I can give you a more concrete example of how this looks in practice.

[romanatexn]

Hi @mbrandonw ! Thanks for the answer, essentially I want to do something like this:

@MainActor
class ViewModel {
    enum Event { case onTask }
    func process(_ event: Event) {}
}


struct ViewModelDependency : Sendable {
    var process: @Sendable (_ event: ViewModel.Event) async -> ()
}

extension ViewModelDependency: DependencyKey {
    static var liveValue: ViewModelDependency {
        let vm  = ViewModel()
        return ViewModelDependency(
            process: { e in await vm.process(e) }
        )
    }
}

It works and checks, but the problem is I'd like to minimize possible context switching and somehow convince compiler that ViewModelDependency will be used exclusively from MainActor and provide this signature

struct ViewModelDependency : Sendable {
    var process: @Sendable (_ event: ViewModel.Event) -> ()
}

[Narsail]

Naive question: If you want it to only work with the MainActor, isn't using Sendable the wrong approach here? And couldn't you just declare your process function with @mainactor?

struct ViewModelDependency {
    var process: @MainActor (_ event: ViewModel.Event) -> ()
}

[romanatexn]

Tried it, but still got warnings:
if I don't mark ViewModelDependency as Sendable I get
Type 'ViewModelDependency' does not conform to the 'Sendable' protocol (so I shouldn't just return it from static var liveValue)

If I mark it as Sendable I get
Stored property 'process' of 'Sendable'-conforming struct 'ViewModelDependency' has non-sendable type '@MainActor (ViewModel.Event) -> ()

[kamcma]

The Web Sockets case study provides an example of how a dependency can wrap an actor, rather than being the actor. In this case, it is its own global actor, but there are lots of things you could do here, including using the main actor.

[romanatexn]

Yes, but it's also using context switching, meaning there's an await inside wrapper

essentially same as here #3209 (reply in thread)

[kamcma]

I'm not certain what you want is possible. Dependency clients registered with swift-dependencies must be sendable; it's right here in the DependencyKey protocol. If you want to interact with the main actor in the implementation of a dependency, yes, you will incur a thread-hop. It's just the API design of the swift-dependencies library. Can you explain why a thread-hop is not acceptable? I believe the thread hop is actually squashed away in TCA tests because the TestStore makes use of the withMainSerialExecutor tool brought in transitively from swift-concurrency-extras.

A possible alternative you could explore. Fall back to the pre-swift-dependencies style of dependencies: the environment. Make a client interface that you do not register with swift-dependencies, and are thus unconstrained to mark the whole thing MainActor if you wish. You hold on to this client as plain stored property on the reducer. You know the store lives on the main actor, so the compiler should be happy to let you interact with it. You lose some of the ergonomic niceties of swift-dependencies, such as having to pass the client around explicitly, but you can still make live/test/preview implementations, just as we all did with TCA before swift-dependencies existed. I think that is the cost of making a non-sendable dependency.