SwiftUI View Refactor

Overview

SwiftUI ビューを小規模で明示的で安定した View 型へリファクタリングします。デフォルトは vanilla SwiftUI を使用：ローカル状態はビューに、共有依存関係は environment に、ビジネスロジックはサービス/モデルに、ビューモデルはリクエストまたは既存コードが明確に要求する場合のみ使用します。

Core Guidelines

1) View の順序 (上 → 下)

• 既存ファイルがより強いローカル規約を持つ場合を除き、この順序を適用してください。
• Environment
• private/public let
• @State / その他のストアドプロパティ
• computed var (ビュー以外)
• init
• body
• computed view builders / その他のビューヘルパー
• ヘルパー / async 関数

2) デフォルトは MV、MVVM ではない

• ビューは軽量な状態表現とオーケストレーションポイントであるべきで、ビジネスロジックのコンテナではありません。
• ビューモデルに手を出す前に、@State、@Environment、@Query、.task、.task(id:)、onChange を優先的に使用してください。
• サービスと共有モデルを @Environment 経由でインジェクトし、ドメインロジックをビュー本体ではなくサービス/モデルに保ちます。
• ローカルビューの状態をミラーリングしたり、environment の依存関係をラップするだけのためにビューモデルを導入しないでください。
• 画面が大きくなっている場合は、新しいビューモデルレイヤーを発明する前に、UI を小規模なサブビューに分割してください。

3) computed some View ヘルパーより専用サブビュー型を強く優先

• 約 1 画面よりも長いか、複数の論理的なセクションを含む body プロパティにフラグを立ててください。
• 非自明なセクション、特に状態、async 作業、分岐を持つか、独自のプレビューがあるセクションについては、専用の View 型の抽出を優先します。
• computed some View ヘルパーは稀で小規模に保ってください。private var header: some View スタイルのフラグメントで画面全体を構築しないでください。
• 親の全状態を渡すのではなく、小規模で明示的な入力（データ、バインディング、コールバック）を抽出されたサブビューに渡します。
• 抽出されたサブビューが再利用可能または独立して意味のあるものになった場合は、独自のファイルに移動してください。

優先する例：

var body: some View {
    List {
        HeaderSection(title: title, subtitle: subtitle)
        FilterSection(
            filterOptions: filterOptions,
            selectedFilter: $selectedFilter
        )
        ResultsSection(items: filteredItems)
        FooterSection()
    }
}

private struct HeaderSection: View {
    let title: String
    let subtitle: String

    var body: some View {
        VStack(alignment: .leading, spacing: 6) {
            Text(title).font(.title2)
            Text(subtitle).font(.subheadline)
        }
    }
}

private struct FilterSection: View {
    let filterOptions: [FilterOption]
    @Binding var selectedFilter: FilterOption

    var body: some View {
        ScrollView(.horizontal, showsIndicators: false) {
            HStack {
                ForEach(filterOptions, id: \.self) { option in
                    FilterChip(option: option, isSelected: option == selectedFilter)
                        .onTapGesture { selectedFilter = option }
                }
            }
        }
    }
}

避ける例：

var body: some View {
    List {
        header
        filters
        results
        footer
    }
}

private var header: some View {
    VStack(alignment: .leading, spacing: 6) {
        Text(title).font(.title2)
        Text(subtitle).font(.subheadline)
    }
}

3b) body からアクションとサイドエフェクトを抽出

• 非自明なボタンアクションをビュー本体にインラインで保たないでください。
• ビジネスロジックを .task、.onAppear、.onChange、.refreshable に埋め込まないでください。
• ビューから小規模なプライベートメソッドを呼び出すことを優先し、実際のビジネスロジックをサービス/モデルに移動してください。
• 本体はビューコントローラーのようではなく、UI のように読まれるべきです。

Button("Save", action: save)
    .disabled(isSaving)

.task(id: searchText) {
    await reload(for: searchText)
}

private func save() {
    Task { await saveAsync() }
}

private func reload(for searchText: String) async {
    guard !searchText.isEmpty else {
        results = []
        return
    }
    await searchService.search(searchText)
}

4) 安定したビュー木を保つ (トップレベルの条件付きビュー交換を避ける)

• if/else 経由で完全に異なるルートブランチを返す body または computed ビューを避けてください。
• 条件をセクション/修飾子内に置いた単一の安定した基本ビューを優先します (overlay、opacity、disabled、toolbar など)。
• ルートレベルのブランチ交換は ID チャーンを引き起こし、より広い無効化とさらなる再計算を招きます。

優先する例：

var body: some View {
    List {
        documentsListContent
    }
    .toolbar {
        if canEdit {
            editToolbar
        }
    }
}

避ける例：

var documentsListView: some View {
    if canEdit {
        editableDocumentsList
    } else {
        readOnlyDocumentsList
    }
}

5) ビューモデルの処理 (既に存在するか明示的にリクエストされた場合のみ)

• ビューモデルをデフォルトではなく、レガシーまたは明示的な必要性パターンとして扱ってください。
• リクエストまたは既存コードが明確に要求しない限り、ビューモデルを導入しないでください。
• ビューモデルが存在する場合は、可能な限りそれを非オプショナルにしてください。
• init 経由でビューに依存関係を渡し、ビューの init でビューモデルを作成してください。
• bootstrapIfNeeded パターンおよび他の遅延セットアップ回避策を避けてください。

例（Observation ベース）：

@State private var viewModel: SomeViewModel

init(dependency: Dependency) {
    _viewModel = State(initialValue: SomeViewModel(dependency: dependency))
}

6) Observation の使用

• iOS 17+ の @Observable 参照型については、所有ビューに @State として保存してください。
• observables を明示的に下に渡してください。UI が本当に必要としない限りオプショナル状態を避けてください。
• デプロイメントターゲットが iOS 16 以前を含む場合は、所有者で @StateObject を、レガシー observable モデルをインジェクトするときに @ObservedObject を使用してください。

Workflow

1. ビューを順序付けルールに合わせて並び替えます。
2. body からインラインアクションとサイドエフェクトを削除します。ビジネスロジックをサービス/モデルに移動し、ビューには薄いオーケストレーションのみを保ちます。
3. 専用サブビュー型を抽出して長い本体を短縮します。多くの computed some View ヘルパーで画面を再構築しないでください。
4. 安定したビュー構造を確保します。トップレベルの if ベースのブランチ交換を避け、条件をローカライズされたセクション/修飾子に移動してください。
5. ビューモデルが存在するか明示的に必要な場合、オプショナルビューモデルを init で初期化されたノンオプショナル @State ビューモデルに置き換えてください。
6. Observation の使用を確認します。iOS 17+ ではルート @Observable モデル向けに @State を、デプロイメントターゲットが必要とする場合のみレガシーラッパーを使用します。
7. 動作を維持します。リクエストされない限り、レイアウトまたはビジネスロジックを変更しないでください。

Notes

• 大規模な条件付きブロックおよび大規模な computed some View プロパティより小規模で明示的なビュー型を優先してください。
• computed ビュー builders を body の下に、非ビュー computed vars を init の上に保ってください。
• 優れた SwiftUI リファクタリングは、ビューが混合レイアウトと命令型ロジックではなく、データフローとレイアウトとして上から下へ読むようにします。
• MV ファーストガイダンスと根拠については、references/mv-patterns.md を参照してください。

Large-view handling

SwiftUI ビューファイルが約 300 行を超える場合、積極的に分割します。複数の computed プロパティ内に複雑さを隠すのではなく、意味のあるセクションを専用の View 型に抽出します。アクションとヘルパー用の private 拡張と // MARK: - コメントを使用します。ただし、拡張を巨大な画面を小規模なビュー型に分割する代わりとして扱わないでください。抽出されたサブビューが再利用されるか、独立して意味のあるものの場合、独自のファイルに移動してください。