Sending actions from afar, or using delegates in TCA

[sbwilson]

Just a curious little question on how to send an action into a reducer from inside a delegate method...

I'm working on a macOS application that needs to communicate with my own remote REST endpoints protected by OAuth2, currently using AlamoFire, OAuthSwift and the OAuth2SwiftAlamofire bridge, wrapped inside an Endpoint class. As part of the authentication flow, OAuth2Swift provides the ability to provide a delegate class (implementing OAuthSwiftURLHandlerType) that provides a method for specifying how to display this login page. The default is to show it in the user's default web browser, but I'd like to have this appear inside a sheet or an embedded WebView (since the application is a full-screen kiosk-like application, and ignoring the fact that this is probably not a great idea security-wise, since in my case it's an internal application for an internal service containing non-sensitive data, so less chance of harm from this bad practice).

My current reducer body looks similar to:

Reduce { state, action in 
    switch action { 
        case .connectEndpointClicked: 
            return .run { [endpoint = state.endpoint] send in 
                let connectionResult = await endpoint.connect() 
                await send(.testCompleted(connectionResult) 
            }
        case let .testCompleted(result):
            state.testResult = result 
            return .none
        case let .handleURL(url): 
            state.oauthURL = url // and whatever else is needed to display this URL inside the sheet / embedded WebView 
            return .none
    }
}

and for the URL handler:

open class MyURLHandler: NSObject, OAuthSwiftURLHandlerType {
    public func handle(_ url: URL) { 
        // TODO: pass the URL back into the reducer?
    }
}

What would be the recommended way to have my URL handler pass the URL back into this reducer? Or more generally, how does one handle the desire to send data from inside a delegate back to a reducer part-way through an Effect.run call? Or is this just a big design stink and I should redesign this?

Thanks!

[mbrandonw]

Hi @sbwilson, it's hard to give concrete advice without seeing more code, but it does seem like something you would want to use here is the fact that Effect's can be constructed in a way that emit multiple times.

For example, your connect() endpoint should probably return a publisher or async sequence so that it can emit data at any time, and then you send that data back into your reducer:

// If using publisher
return .publisher {
  endpoint.connect()
    .map(Action.response)
}

// If using async sequence
return .run { send in 
  for await data in endpoint.response() {
    await send(.response(data))
  }
}

That's the basic idea.

One thing that definitely gives me pause about your code is the fact that your state holds onto something that is capable of doing side effects (endpoint). Typically these things should be put into the dependency system, not in state.

[sbwilson]

Thanks for your reply! That's an interesting idea – emitting the progress of the connection operation makes a lot of sense, even outside this discussion, but it is still a bit foreign to my brain that is finding old objective-C design patterns a bit harder to discard. I'm particularly glad it looks like I don't need to do something strange like pass a Send into endpoint.connect()!

So to further your example, if I can have my OAuthSwift URL handler callback pass the URL back to the Endpoint instance that owns it, and return that URL into an async sequence from connect(), I could therefore change the .connectEndpointClicked case to be more like this?

Reduce { state, action in 
    switch action { 
        case .connectEndpointClicked: 
            return .run { [endpoint = state.endpoint] send in 
                for await connectionProgress = endpoint.connect() {
                    if case let .urlCallback(url) == connectionProgress { 
                        await send(.handleURL(url))
                    }
                    // ... or probably a switch over the connectionProgress ... 
                }
            }
    }
}

With regards to Endpoint residing inside the state – this example comes from the "create new endpoint" form, where upon a successful connection using the form's contents, we store the details inside an EndpointManager, which is in turn managed by Dependency. In normal operation, the user selects the endpoint they want to work with from the EndpointManager, which marks as the "current" endpoint, and all REST requests in the application are made through that. Doing it this way seemed a little simpler than creating a value type EndpointInformation and creating an Endpoint from this...