Replies: 1 comment 2 replies
-
|
I'm unsure of the relationship between struct AuthenticationClient {
public var userInfo: @Sendable (LoginRequest) async throws -> UserInfo
public var update: @Sendable (UserInfo) async throws -> Void
public var isAuthorized: @Sendable () async throws -> Bool
}Your live implementation would look something like this extension AuthenticationClient {
static let live = Self(
userInfo: { request in
let usersSvc: UsersService = AirHubSDK.userService()
return try await usersSvc.login(email: request.email, password: request.password)
}, update: { userInfo in
await AuthDataHolderClient.shared.update(authData: .init(
userId: userInfo.userId,
accessToken: userInfo.token,
refreshToken: userInfo.refreshToken
))
}, isAuthorized: {
await AirHubSDK.isAuthorized
})
}and a mocked version could be extension AuthenticationClient {
static let mock = Self(
userInfo: { request in
return UserInfo(userId: "123", accessToken: "AAA", refreshToken: "111")
}, update: { userInfo in
return ()
}, isAuthorized: {
return true
})
} |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
HI!
I have 2 questions regarding how to deal with dependencies within the TCA.
So have a simple client like this:
public struct AuthenticationClient: Sendable {
public var login: @sendable (LoginRequest) async throws -> Bool
}
And then with a static instance:
public extension AuthenticationClient {
static let
default= Self(login: { request in
}
What would be a good way to adjust the default impl. So that the userservice (from the AirHub SDK) is mockable and the same for the AuthDataHolderClient with respect to the TCA pattern. Making the user service static on the AuthenticationClient causes a warning of a non sendable property on a Sendable struct...
Beta Was this translation helpful? Give feedback.
All reactions