TAGS
주제로 글을 찾습니다
Tech, Domain, Journal 글에 붙은 공통 태그를 모았습니다.
TCA Under the Hood
TCA(The Composable Architecture)를 쓰면서 "왜 이렇게 동작하지?" 싶었던 순간들이 있었다. send가 동기인 것 같으면서도 Effect가 비동기고, 같은 액션을 두 번 보내면 경고가 뜨고, scope를 호출할 때마다 새 Store가 생기지 않는 것처럼 느껴지고.
처음 열린 KWDC 2023
처음 열린 KWDC 2023에 참석해 TCA와 Apple 플랫폼 이야기를 듣고 개발자들을 만난 기록.
컬렉션과 바인딩: forEach와 IdentifiedArray, 바인딩 변수
앞 장까지로 화면 하나와 화면 사이 전환을 다뤘다. 남은 건 화면 안쪽에서 자주 나오는 두 패턴이다. 하나는 목록이고, 하나는 폼이다.
화면 전환: iOS 15 대응부터 iOS 16 Stack까지
화면이 하나일 때는 1장의 단방향 흐름으로 충분하다. 문제는 화면이 여러 개가 되면서 시작된다. 목록에서 상세로 들어가고, 거기서 편집 시트를 띄우고, 저장하면 두 단계를 한 번에 닫는다. 이런 전환을 뷰 코드에서 명령형으로 밀고 당기면, 지금 어느 화면이 떠 있는지가 다시 여기저기 흩어진다. 1장에서 겨우 좁혀 놓은 추적 가능성이 화면 전환에서 무너지는 것이다.
의존성 관리와 테스트
1장의 Effect 안에서 apiClient.fetchItems()를 불렀다. 문제는 이 한 줄이 테스트를 통째로 어렵게 만든다는 데 있다. 테스트가 진짜 서버를 부르면 네트워크 상태에 따라 결과가 달라지고, 느리고, 서버가 특정 상황을 돌려주게 만들 수도 없다. 현재 시간, 랜덤 값, 파일 시스템도 같은 문제를 갖는다. 결과가 바깥 환경에 따라 달라지는 코드는 그대로는 테스트할 수 없다.
State·Action·Reducer·Store와 단방향 흐름
SwiftUI로 화면 몇 개를 만들어 보면 상태 관리가 곧 벽이 된다. 작은 뷰는 @State로 충분하지만, 화면이 커지면 여러 뷰가 같은 값을 공유해야 하고 @ObservedObject, @EnvironmentObject가 섞여 들어온다. 문제는 값을 바꾸는 경로가 정해져 있지 않다는 데 있다. 어떤 버튼이 어디의 상태를 직접 고치고, 그 변화가 또 다른 상태를 건드리기 시작하면 "지금 이 값이 왜 이렇게 됐는지"를 되…