코드 전문
import ComposableArchitecture
import SwiftUI
private let readMe = """
This screen demonstrates how to introduce side effects into a feature built with the \
Composable Architecture.
A side effect is a unit of work that needs to be performed in the outside world. For example, an \
API request needs to reach an external service over HTTP, which brings with it lots of \
uncertainty and complexity.
Many things we do in our applications involve side effects, such as timers, database requests, \
file access, socket connections, and anytime a clock is involved (such as debouncing, \
throttling, and delaying), and they are typically difficult to test.
This application has a simple side effect: tapping "Number fact" will trigger an API request to \
load a piece of trivia about that number. This effect is handled by the reducer, and a full test \
suite is written to confirm that the effect behaves in the way we expect.
"""
@Reducer
struct EffectsBasics {
@ObservableState
struct State: Equatable {
var count = 0
var isNumberFactRequestInFlight = false
var numberFact: String?
}
enum Action {
case decrementButtonTapped
case decrementDelayResponse
case incrementButtonTapped
case numberFactButtonTapped
case numberFactResponse(Result<String, Error>)
}
@Dependency(\.continuousClock) var clock
@Dependency(\.factClient) var factClient
@Dependency(\.testDependency) var testDependency
private enum CancelID { case delay }
var body: some Reducer<State, Action> {
Reduce { state, action in
switch action {
case .decrementButtonTapped:
state.count -= 1
state.numberFact = nil
// Return an effect that re-increments the count after 1 second if the count is negative
return state.count >= 0
? .none
: .run { send in
try await self.clock.sleep(for: .seconds(1))
await send(.decrementDelayResponse)
}
.cancellable(id: CancelID.delay)
case .decrementDelayResponse:
if state.count < 0 {
state.count += 1
}
return .none
case .incrementButtonTapped:
state.count += 1
state.numberFact = nil
print(testDependency.count)
return state.count >= 0
? .cancel(id: CancelID.delay)
: .none
case .numberFactButtonTapped:
state.isNumberFactRequestInFlight = true
state.numberFact = nil
// Return an effect that fetches a number fact from the API and returns the
// value back to the reducer's `numberFactResponse` action.
return .run { [count = state.count] send in
await send(.numberFactResponse(Result { try await self.factClient.fetch(count) }))
}
case let .numberFactResponse(.success(response)):
state.isNumberFactRequestInFlight = false
state.numberFact = response
return .none
case .numberFactResponse(.failure):
// NB: This is where we could handle the error is some way, such as showing an alert.
state.isNumberFactRequestInFlight = false
return .none
}
}
}
}
struct EffectsBasicsView: View {
let store: StoreOf<EffectsBasics>
@Environment(\.openURL) var openURL
var body: some View {
Form {
Section {
AboutView(readMe: readMe)
}
Section {
HStack {
Button {
store.send(.decrementButtonTapped)
} label: {
Image(systemName: "minus")
}
Text("\(store.count)")
.monospacedDigit()
Button {
store.send(.incrementButtonTapped)
} label: {
Image(systemName: "plus")
}
}
.frame(maxWidth: .infinity)
Button("Number fact") { store.send(.numberFactButtonTapped) }
.frame(maxWidth: .infinity)
if store.isNumberFactRequestInFlight {
ProgressView()
.frame(maxWidth: .infinity)
// NB: There seems to be a bug in SwiftUI where the progress view does not show
// a second time unless it is given a new identity.
.id(UUID())
}
if let numberFact = store.numberFact {
Text(numberFact)
}
}
Section {
Button("Number facts provided by numbersapi.com") {
openURL(URL(string: "http://numbersapi.com")!)
}
.foregroundStyle(.secondary)
.frame(maxWidth: .infinity)
}
}
.buttonStyle(.borderless)
.navigationTitle("Effects")
}
}
#Preview {
NavigationStack {
EffectsBasicsView(
store: Store(initialState: EffectsBasics.State()) {
EffectsBasics()
}
)
}
}
import ComposableArchitecture
import Foundation
@DependencyClient
struct FactClient {
var fetch: @Sendable (Int) async throws -> String
}
extension DependencyValues {
var factClient: FactClient {
get { self[FactClient.self] }
set { self[FactClient.self] = newValue }
}
}
extension FactClient: DependencyKey {
/// This is the "live" fact dependency that reaches into the outside world to fetch trivia.
/// Typically this live implementation of the dependency would live in its own module so that the
/// main feature doesn't need to compile it.
static let liveValue = FactClient(
fetch: { number in
try await Task.sleep(for: .seconds(1))
let (data, _) = try await URLSession.shared
.data(from: URL(string: "http://numbersapi.com/\(number)/trivia")!)
return String(decoding: data, as: UTF8.self)
}
)
/// This is the "unimplemented" fact dependency that is useful to plug into tests that you want
/// to prove do not need the dependency.
static let testValue = Self()
}
@DependencyClient
struct TestDependency {
var count = 0
mutating func increment() {
count += 1
}
}
extension DependencyValues {
var testDependency: TestDependency {
get { self[TestDependency.self]}
set { self[TestDependency.self] = newValue}
}
}
extension TestDependency: DependencyKey {
static var liveValue: TestDependency {
return .init()
}
}리드미 해석
This screen demonstrates how to introduce side effects into a feature built with the Composable Architecture.
A side effect is a unit of work that needs to be performed in the outside world. For example, an API request needs to reach an external service over HTTP, which brings with it lots of uncertainty and complexity.
Many things we do in our applications involve side effects, such as timers, database requests, file access, socket connections, and anytime a clock is involved (such as debouncing, throttling, and delaying), and they are typically difficult to test.
This application has a simple side effect: tapping "Number fact" will trigger an API request to load a piece of trivia about that number. This effect is handled by the reducer, and a full test suite is written to confirm that the effect behaves in the way we expect.
이 화면은 컴포저블 아키텍처로 구축한 기능에 사이드 이펙트를 도입하는 방법을 보여줍니다.
사이드 이펙트는 외부 세계에서 수행해야 하는 작업의 단위입니다. 예를 들어, API 요청은 HTTP를 통해 외부 서비스에 도달해야 하는데, 여기에는 많은 불확실성과 복잡성이 수반됩니다.
애플리케이션에서 수행하는 많은 작업에는 타이머, 데이터베이스 요청, 파일 액세스, 소켓 연결, 디바운싱, 스로틀링, 지연 등 클럭과 관련된 부작용이 수반되며 일반적으로 테스트하기 어렵습니다.
이 애플리케이션에는 간단한 부작용이 있습니다. '숫자 사실'을 탭하면 해당 숫자에 대한 퀴즈를 로드하는 API 요청이 트리거됩니다. 이 효과는 리듀서가 처리하며, 이 효과가 예상한 대로 작동하는지 확인하기 위해 전체 테스트 스위트를 작성합니다.
Translated with DeepL.com (free version)
동작 화면
TCA의 구조 살펴보기
TCA의 기본 구조입니다. Reducer는 내부에 State와 Action에 관해서 알고 있습니다. View는 내부 Property로 Store을 갖고 있습니다. 이 Stroe에 Action을 보내고 Reducer는 적절하게 Action에 따라 State를 Swiftch합니다. 그런데 만약 View에서 API요청이나 외부로 부터 업데이트 받아야 하는 일이 생기면 어떻게 해야 할까요? 그럴때는 외부 Dependency 를 통해서 업데이트 해야 합니다. 이를 TCA에서는 Effect를 업데이트 한다고 합니다.
Dependencies에 대해서(공식문서)
Dependencies in an application are the types and functions that need to interact with outside systems that you do not control. Classic examples of this are API clients that make network requests to servers, but also seemingly innocuous things such as UUID and Date initializers, and even schedulers and clocks, can be thought of as dependencies.
By controlling the dependencies our features need to do their job we gain the ability to completely alter the execution context a features runs in. This means in tests and Xcode previews you can provide a mock version of an API client that immediately returns some stubbed data rather than making a live network request to a server.
애플리케이션의 종속성은 사용자가 제어하지 않는 외부 시스템과 상호 작용해야 하는 유형 및 기능을 말합니다. 대표적인 예로는 서버에 네트워크 요청을 하는 API 클라이언트가 있지만, UUID 및 날짜 초기화기, 심지어 스케줄러 및 시계와 같이 겉보기에는 무해해 보이는 것들도 종속성으로 생각할 수 있습니다.
기능이 작동하는 데 필요한 종속성을 제어함으로써 기능이 실행되는 실행 컨텍스트를 완전히 변경할 수 있습니다. 즉, 테스트 및 Xcode 미리 보기에서 서버에 실시간 네트워크 요청을 하는 대신 일부 스텁된 데이터를 즉시 반환하는 API 클라이언트의 모의 버전을 제공할 수 있습니다.
공식 문서에서는 다음과 같은 이유로 Dependencies를 Manually 하게 다루면 Problem을 일으킬 수 있다고 합니다.
- Uncontrolled dependencies make it difficult to write fast, deterministic tests because you are susceptible to the vagaries of the outside world, such as file systems, network connectivity, internet speed, server uptime, and more.
- Many dependencies do not work well in SwiftUI previews, such as location managers and speech recognizers, and some do not work even in simulators, such as motion managers, and more. This prevents you from being able to easily iterate on the design of features if you make use of those frameworks.
- Dependencies that interact with 3rd party, non-Apple libraries (such as Firebase, web socket libraries, network libraries, etc.) tend to be heavyweight and take a long time to compile. This can slow down your development cycle.
제어되지 않은 종속성은 파일 시스템, 네트워크 연결, 인터넷 속도, 서버 가동 시간 등과 같은 외부 세계의 변수에 영향을 받기 때문에 빠르고 결정론적인 테스트를 작성하기 어렵게 만듭니다.
위치 관리자 및 음성 인식기와 같은 많은 종속성이 SwiftUI 미리보기에서 제대로 작동하지 않으며, 모션 관리자 등과 같은 일부 종속성은 시뮬레이터에서도 작동하지 않습니다. 따라서 이러한 프레임워크를 사용하는 경우 기능 디자인을 쉽게 수정 할 수 없습니다.
Apple이 아닌 타사 라이브러리(예: Firebase, 웹 소켓 라이브러리, 네트워크 라이브러리 등)와 상호 작용하는 종속성은 무겁고 컴파일하는 데 시간이 오래 걸리는 경향이 있습니다. 이로 인해 개발 주기가 느려질 수 있습니다.
- How can you propagate dependencies throughout your entire application in a way that is more ergonomic than explicitly passing them around everywhere, but safer than having a global dependency?
- How can you override dependencies for just one portion of your application? This can be handy for overriding dependencies for tests and SwiftUI previews, as well as specific user flows such as onboarding experiences.
- How can you be sure you overrode all dependencies a feature uses in tests? It would be incorrect for a test to mock out some dependencies but leave others as interacting with the outside world.
- 모든 곳에 명시적으로 종속성을 전달하는 것보다 더 인체공학적이면서 전역 종속성을 갖는 것보다 더 안전한 방식으로 전체 애플리케이션에 종속성을 전파하려면 어떻게 해야 할까요?
- 애플리케이션의 한 부분에 대한 종속성을 어떻게 재정의할 수 있을까요? 테스트 및 SwiftUI 미리 보기뿐만 아니라 온보딩 경험과 같은 특정 사용자 흐름에 대한 종속성을 재정의하는 데 유용할 수 있습니다.
- 기능이 테스트에서 사용하는 모든 종속성을 재정의했는지 어떻게 확인할 수 있나요? 테스트에서 일부 종속성을 모킹하고 다른 종속성은 외부 세계와 상호 작용하는 것으로 남겨두는 것은 올바르지 않습니다.
Reducer에서 Dependencies을 활용하기
Reducer에 사용하는 Dependencies를 활용하기 위해서 Dependencies는 다음과 같은 것을 먼저 확인해야 합니다.
1. @DependencyClient 가 있는 Model만들기
2. Extension을 통해서 변수 선언하기
3. Model에 DependencyKey Protocol 선언하기
4. TCA Dependencies System에 쓰일 Static변수 설정하기
@DependencyClient
struct FactClient {
var fetch: @Sendable (Int) async throws -> String
}
extension DependencyValues {
var factClient: FactClient {
get { self[FactClient.self] }
set { self[FactClient.self] = newValue }
}
}
extension FactClient: DependencyKey {
static let liveValue = FactClient(
fetch: { number in
try await Task.sleep(for: .seconds(1))
let (data, _) = try await URLSession.shared
.data(from: URL(string: "http://numbersapi.com/\(number)/trivia")!)
return String(decoding: data, as: UTF8.self)
}
)
static let testValue = Self()
}
5. 필요한 부분에서 활용하기 (현재는 비동기 이면서, 통신 이후에 특정 결과값을 다음 Action을 통해 Send하고 있습니다.)
@Dependency(\.factClient) var factClient
var body: some Reducer ...
// code. ..
case .numberFactButtonTapped:
state.isNumberFactRequestInFlight = true
state.numberFact = nil
// Return an effect that fetches a number fact from the API and returns the
// value back to the reducer's `numberFactResponse` action.
return .run { [count = state.count] send in
await send(.numberFactResponse(Result { try await self.factClient.fetch(count) }))
}
return .run
Reducer에서는 Effect를 Return 합니다. Effect에서 다른 Action을 호출하기 위해서 run 구문을 통해서 실행합니다.
Dependency 를 상황에 따라 Customizing하기
View를 만들 때 사용하는 Reducer에 method Chaining으로 DepenDency를 직접 조종 할 수 있습니다. 현재는 HardCoding된 Custom Dependency를 리턴하게 만들어 주었습니다.
EffectsBasicsView(
store: Store(initialState: EffectsBasics.State()) {
EffectsBasics()
.dependency(\.factClient, FactClient(
fetch: { number in
try await Task.sleep(for: .seconds(0))
let (data, _) = try await URLSession.shared
.data(from: URL(string: "http://numbersapi.com/\(number)/trivia")!)
return "Custom Dependency"
}
))
}
)
Dependency를 State처럼 활용할 수 있을까? " No, absolutely"
Dependency는 절대로 State처럼 활용할 수 없습니다. 눈치빠른 분들은 아시겠지만, Dependency를 Reducer에서 불러올 때 TCA Dependency시스템에 있던 값을 꺼내옵니다. 이 값은 keypath로 가져옵니다. 보통 KeyPath로 가져오면 get-only 입니다.
그러면 ReferenceType으로 선언하면 안될까라는 질문이 있을 수 있지만, ReferenceType은 맨 처음 @DependencyClient 매크로를 활용할 수 없습니다. 또한 TCA의 철학역시 함수형을 지향하기 때문에, Dependency는 함수형 처럼 만들어야 합니다.(동일한 입력에 동일한 출력값을 뱉어내게 디자인 해야 합니다.) 그렇기에 Dependency에서 mutating을 통한 값으 변화가 이루어지면 안됩니다.
실제로 mutating함수를 만들어서 실행하면 다음과 같은 경고 메시지가 발생합니다 .
게시물은 TCA 라이브러리의 CaseStudies를 직접 작성해보고 어떻게 작동하는지에 대해서 공부하기 위해서 작성했습니다.
참고 자료
