TextField 에 Binding 으로 연결하면 에러 발생

forEach 스코프 구조에서는 스택 요소를 id로 관리합니다 2번같은 수동바인딩을 사용할시 스택의 id 가 바뀌거나 할 경우 id 불일치로 오류가 발생할수있습니다1번같은 tca 바인딩을 사용하면 tca 내부에서 동적으로 관리된다 합니다.꼭 tca 바인딩을 쓰지않아도 정상 동작하는 경우가 있으나 일부 저런 오류가 나타날수 있습니다

예제 빌드시 The compiler is unable to type-check this expression in reasonable time 에러 발생

The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressionsTCA가 복잡한 제너릭 구조가 많아서 코드가 복잡해지면 타입 추론이 길어지면서 컴파일 에러로 저런 모호한 메시지를 보여주는 경우가 많습니다.질문자님 처럼 함수분리를 하거나 명시적으로 타입을 넣어줘서 타입추론을 쉽게 해줘야합니다.

xcode 26.2 에서 ReducerOf<Self> 이슈

안녕하세요 강의는 Xcode 16.2 버전으로 작성되었습니다.xcode 26버전에서 main actor isolation 을 기본값으로 쓰게 되면서 Reducer 가 암묵적으로 MainActor가 되며 TCA 라이브러리와 문제가 발생했다합니다. 관련해서 논의가 있으나 TCA측은 swift 버그로 인식중이고 아직 업데이트는 안된거같네요 https://github.com/pointfreeco/swift-composable-architecture/discussions/3733질문자님처럼 State,Action 을 사용하시거나 리듀서에 nonisolated 을 붙여주는 해결 방법이 있습니다

해당 강의에서 나오는 노션 링크는 따로 제공안되나요 ?

안녕하세요! 노션링크 강의노트에 작성했습니다 영상 아래 수업노트보기 를 통해 접근가능합니다

해당 강의는 추가 오픈하는건가요?

안녕하세요 강의 빠르게 들으셨군요! 네 아직 강의 개설 진행중입니다준비한 강의는 7월말 까지는 마무리 지을 예정이고 연말 까지 추가 강의 계획중입니다감사합니다

유즈케이스 프로토콜과 구현체의 분리 이유

안녕하세요 !usecase 프로토콜을 사용하여 추상화된 인터페이스를 구현했고 viewModel이 이를 의존하는 관계를 가지게 함이 목적입니다 가장 큰 장점은 말씀하신대로 의존성을 약화시키는 겁니다 usecase 구현체에 의존하는것보다추상화에 의존하게하여 의존성을 약화시켜 usecase 수정이 일어났을때 viewModel이 비교적취약하지 않게합니다 또 ViewModel 테스트 코드 작성에 용이 해질수있습니다usecaseProtocol을 준수하는 MockUsecase를 만들수 있기 때문입니다!

즐겨찾기 탭에서 페이지네이션 422 서버 에러

오류가 있었군요 빨리 수정 하도록 하겠습니다네 작성하신대로 탭 상태에 따라 필터를 걸어서 api 상태일때만 이벤트를 트리거 하면 됩니다!

의존성 주입에 관하여 질문있습니다.

네 맞습니다 의존성주입을 위해서 전환시 모두 객체 생성하여야 합니다 그렇게되면 뷰컨트롤러가 커지게될수 있는데 coordinator 패턴을 사용한다면 coordinator 내부에서 모든 객체 생성 및 네비게이션을 구현하고 뷰컨트롤러에서 coordinator 의존하여 사용하시면 됩니다이전화면과 다음화면에 데이터가 유지되어야하거나 같은 프로세스인경우(ex 회원가입 이메일입력-> 비민번호입력 ) 뷰모델을 공유하기도하지만 각각 다른 기능 을 가진다면 각각 뷰모델을가져가는게 좋아보입니다!

NetworkManager의 tokenHeader 관련 질문 드립니다!

네 각 api 마다 요구하는 헤더가 다르므로 NetworkManager의 fetchData 파라미터로 헤더를 받아오면 좋습니다!강의가 도움이 되어 다행입니다 좋은질문 감사해요~!

[클린 아키텍쳐] 로컬 Json 파싱

파일은 리포지토리에서 파일매니저 접근하시면 좋을듯 합니다Search api가 아니라 직접 로직을 수행한다면 기능은 usecase 에서 정의하는게 좋아보입니다 load 도 그렇구요 단순한 기능의 앱이라면 간단히 mvvm 만 사용해도 뷰모델이 커지지 않겠지만 확장성을 고려한다면 클린 아키텍쳐가 좋아보입니다!