Skip to content

CONCEPTUAL_OVERVIEW.md

Latest commit

 

History

History
161 lines (120 loc) · 5.2 KB

CONCEPTUAL_OVERVIEW.md

File metadata and controls

161 lines (120 loc) · 5.2 KB

SwiftUIExamples: Conceptual Design Overview

This document provides a graphical and conceptual overview of the six architectural patterns demonstrated in the SwiftUIExamples repository. Each pattern is illustrated with a Mermaid diagram and a brief explanation of its structure and data flow.

1. ViewOnly Pattern

Purpose: Teach SwiftUI basics and simple state management.

flowchart TD
    A["Parent View (@State)"] -->|"@Binding"| B[Child View]
    B -->|"@Binding"| C[Grandchild View]
    A -.->|State changes propagate down| B
    B -.->|Bindings propagate up| A
Loading
  • State Ownership: Views own their state using @State and pass it down via @Binding.
  • Data Flow: Unidirectional, parent-to-child for state, child-to-parent for updates via bindings.
  • Use Case: Prototypes, learning SwiftUI fundamentals.

2. MVVM Pattern

Purpose: Teach production-ready architecture with separation of concerns.

flowchart TD
    VM["MVVMAppViewModel (@Observable)"]
    VM -->|Observed by| V1[Sidebar View]
    VM -->|Observed by| V2[Content List View]
    VM -->|Observed by| V3[Detail View]
    V1 -->|User selects| VM
    V2 -->|User selects| VM
    V3 -->|User edits| VM
    VM -->|Owns| VM1[SidebarViewModel]
    VM -->|Owns| VM2[ContentListViewModel]
    VM -->|Owns| VM3[SettingsViewModel]
    VM -->|Reads| M[Models]
Loading
  • State Ownership: ViewModels own state, views observe changes.
  • Data Flow: Centralized in MVVMAppViewModel, which coordinates all state.
  • Use Case: Production apps, clear separation of UI and logic.

3. MVVM-C Pattern

Purpose: Teach navigation separation from business logic using Coordinators.

flowchart TD
    C[MVVMCAppCoordinator]
    C -->|Owns| VM1[SidebarViewModel]
    C -->|Owns| VM2[ContentListViewModel]
    C -->|Owns| VM3[SettingsViewModel]
    C -->|Manages| Nav[Navigation State]
    VM1 -->|Observed by| V1[Sidebar View]
    VM2 -->|Observed by| V2[Content List View]
    VM3 -->|Observed by| V3[Detail View]
    V1 -->|User selects| C
    V2 -->|User selects| C
    V3 -->|User edits| C
    C -->|Reads| M[Models]
Loading
  • State Ownership: Coordinator owns navigation state, ViewModels own business logic.
  • Data Flow: Coordinator mediates between navigation and business logic.
  • Use Case: Complex navigation, deep linking, reusable ViewModels.

4. TCA (The Composable Architecture) Pattern

Purpose: Teach functional architecture with unidirectional data flow, composability, and built-in testing.

flowchart TD
    Store[Store]
    Store -->|Holds| State[State]
    Store -->|Accepts| Action[Actions]
    Store -->|Executes| Reducer[Reducer]

    View[View] -->|Reads| State
    View -->|Sends| Action

    Reducer -->|Transforms| State
    State -->|Updates| View

    Reducer -->|Returns| Effect[Effects]
    Effect -->|Sends| Action
Loading
  • State Ownership: Store holds immutable state, reducer creates new state.
  • Data Flow: Unidirectional: View → Action → Reducer → State → View.
  • Use Case: Complex apps needing maximum testability and composability.

5. Redux Pattern

Purpose: Teach predictable state management with pure functions and single source of truth.

flowchart TD
    Store[Redux Store]
    Store -->|Holds| State[App State]
    Store -->|dispatch| Action[Actions]

    View[View] -->|Reads| State
    View -->|dispatch| Action

    Action -->|Sent to| Reducer[Pure Reducer]
    Reducer -->|Returns new| State
    State -->|Updates| View
Loading
  • State Ownership: Store holds global state, only changed via actions.
  • Data Flow: Unidirectional: View → Action → Reducer → New State → View.
  • Use Case: Predictable state, time-travel debugging, web Redux familiarity.

6. VIPER Pattern

Purpose: Teach maximum separation of concerns.

flowchart TD
    V[View] -->|User input| P[Presenter]
    P -->|Updates| V
    P -->|Requests| I[Interactor]
    I -->|Returns| P
    P -->|Requests| R[Router]
    R -->|Navigation| V
    I -->|Reads| E[Entities]
Loading
  • State Ownership: Each layer has a single responsibility.
  • Data Flow: Strictly separated: View ↔ Presenter ↔ Interactor ↔ Entities; Router handles navigation.
  • Use Case: Large apps, strict testing requirements.

Summary Table

Pattern State Owner Navigation Owner Data Flow Use Case
ViewOnly View (@State) View Parent → Child Prototypes, learning basics
MVVM ViewModel ViewModel Centralized Production, clear separation
MVVM-C Coordinator Coordinator Mediated Complex navigation, reuse logic
TCA Store Reducer/Router Unidirectional Functional, testable, composable
Redux Store Reducer/Router Unidirectional Predictable state, debugging
VIPER Each layer Router Strict separation Large, testable, scalable apps

For detailed explanations, see the architecture docs in the Documentation/ folder.