How to design a dependency limited to a specific actor?

[okmaybenot]

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.

[pro100filipp]

Hmm, this sounds rather strange to me. As far as I know, actors' initializers are synchronous – at least they do not require any async context to be run (example from official docs). I've been using actors like this everywhere, and you can try some simple actor example and compile it yourself – I am sure it will compile.
Moreover, according to this proposal, initializers really are synchronous, thus leading to some restrictions on what can be done inside them. And of course, one can make an asynchronous initializer to satisfy one's needs. Maybe I do not know about some hard underneath implementations of actor initialization mechanism that implicitly leads to asynchronous initialization – if so, I'd be very thankful to know about this.

[mbrandonw]

Hi @pro100filipp, apologies! I was thinking of a global actor, not a regular actor. Global actors require isolation in order to instantiate. If your code compiles just fine with full concurrency warnings / Swift 6 mode, then I say go for it!

[pro100filipp]

Ahaha, nice! Because I've already started thinking I was going crazy. By the way, I was pretty close to thinking of using a global actor for a dependency and was wondering how to do this. So, thank you for the tip about wrappers!

[pro100filipp]

@romanatexn answering your question

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

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

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

[tdrraluca]

@mbrandonw Can you please elaborate a bit more on the point below and that was previously mentioned in this thread?

you will need some kind of initialize() async endpoint to create the actor

I have been looking at The Web Sockets case study, but the approach used in this case study consists of accessing the global actor shared instance from the async context of dependency closures. I cannot wrap my head around how adding an initialize() async endpoint can enable the dependency closures to share the same instance of a type that has an actor isolated initialiser.

Many thanks!

[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.

[okmaybenot]

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.