はい、もちろんです！質問してください！プロジェクトのお手伝いができて光栄です！

ありがとうございます！ 初めてTCAに触れたにも関わらず、講義がとても良くできていたので、時間は少しかかりましたが無難（？）に理解もでき、実際のプロジェクトにも適用することができました。 講義で扱ったように、マイページ → [メール / プロフィール / ニックネーム] 編集画面のような単一の深さの画面遷移は理解しやすく、実装もうまくできています！ しかし実際のアプリでは、Instagramのように 投稿 → ユーザーAのプロフィール → ユーザーAのフォローリスト → ユーザーBのプロフィール → ユーザーBのフォローリスト… このような形で継続的に深くなる画面遷移構造がよく登場するのですが、この部分で困難を感じています。 私が講義でどの部分を見落としたのか、 それともこのような多層（？）、ネスト（？）ナビゲーションパターンは元々TCAで少し厄介な方なのか アドバイスをいただきたいです！ 念のため、現在実装した方法をお話しすると マイページに関するナビゲーション構造を作って再利用可能だと思ったのですが、そうしようとすると壊れてしまって、今は… マイページから移動可能なケースを[フォロー/フォロイングリスト、投稿]画面と仮定するなら 例えば 1番タブが投稿関連だとすると、結局マイページに入らなければなりませんよね？ 2番タブがリール/ショーツ関連タブだとすると、ここでも結局マイページに入らなければならないし しかし今は各タブ画面でマイページ画面遷移ケースを全て同じようにコピペして使用中です😢

返信の通知に気づかず、大変遅くなってしまい申し訳ありません。 エラーの原因は分かりかねますが、ナビゲーション構造を作って再利用することは可能です。 例えば、ナビゲーションを担当する子リデューサーを作っておき、そのリデューサーに進入するスコープをすべて指定した上で、 Scope(state: \.profile, action: \.profile) { ProfileFeature() } 親タブごとにStackStateで管理すればよいかと思います。 state.path.append(.profile(ProfileFeature.State(userId: "me"))) ここでは改行がうまく反映されず、読みづらいかもしれませんねㅠㅠ @Reducer struct Path { @ObservableState enum State: Equatable { case profile(ProfileFeature.State) } enum Action { case profile(ProfileFeature.Action) } var body: some ReducerOf<Self> { Scope(state: \.profile, action: \.profile) { ProfileFeature() } } } @Reducer struct HomeTabFeature { @ObservableState struct State: Equatable { var path = StackState<Path.State>() } enum Action { case path(StackAction<Path.State, Path.Action>) case didTapMyProfile } var body: some ReducerOf<Self> { Reduce { state, action in switch action { case .didTapMyProfile: state.path.append(.profile(ProfileFeature.State(userId: "me"))) return .none ...