AgentStack
SKILL verified MIT Self-run

View Refactor

skill-patrickserrano-skills-swiftui-view-refactor · by patrickserrano

Refactor SwiftUI view files for consistent structure, dependency injection, and Observation usage. Use when asked to clean up a SwiftUI view's layout, handle view models safely, or standardize how dependencies are initialized and passed.

No reviews yet
0 installs
13 views
0.0% view→install

Install

$ agentstack add skill-patrickserrano-skills-swiftui-view-refactor

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of View Refactor? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

SwiftUI View Refactor

Overview

Apply consistent structure and dependency patterns to SwiftUI views, focusing on ordering, MV patterns, careful view model handling, and correct Observation usage.

View Ordering (top to bottom)

  1. Environment properties
  2. private/public let constants
  3. @State / other stored properties
  4. Computed var (non-view)
  5. init
  6. body
  7. Computed view builders / view helpers
  8. Helper / async functions

Core Guidelines

1) Prefer MV (Model-View) Patterns

  • Default to MV: views are lightweight state expressions; models/services own business logic
  • Favor @State, @Environment, @Query, task, and onChange for orchestration
  • Inject services and shared models via @Environment
  • Split large views into smaller views instead of introducing a view model

2) Split Large Bodies

If body grows beyond a screen or has multiple logical sections, split it:

var body: some View {
    VStack(alignment: .leading, spacing: 16) {
        HeaderSection(title: title, isPinned: isPinned)
        DetailsSection(details: details)
        ActionsSection(onSave: onSave, onCancel: onCancel)
    }
}

Or use computed view properties in the same file:

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)
    }
}

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

3) View Model Handling (only if already present)

  • Do not introduce a view model unless the request or existing code clearly calls for one
  • If a view model exists, make it non-optional when possible
  • Pass dependencies to the view via init, then into the view model
@State private var viewModel: SomeViewModel

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

4) Observation Usage

  • For @Observable reference types, store them as @State in the root view
  • Pass observables down explicitly as needed
  • Avoid optional state unless required

Refactor Workflow

  1. Reorder the view to match the ordering rules
  2. Favor MV: move orchestration into the view using @State, @Environment, task, onChange
  3. If a view model exists, replace optional with non-optional @State initialized in init
  4. Confirm Observation usage: @State for root @Observable, no redundant wrappers
  5. Keep behavior intact: do not change layout or business logic unless requested

Large-View Handling

When a SwiftUI view file exceeds ~300 lines:

  1. Split using extensions to group related helpers
  2. Move async functions into dedicated private extensions
  3. Use // MARK: - comments (e.g., // MARK: - Actions, // MARK: - Subviews)
  4. Keep main struct focused on stored properties, init, and body
struct LargeView: View {
    @Environment(Store.self) private var store
    @State private var items: [Item] = []

    var body: some View {
        List {
            content
        }
        .task { await loadItems() }
    }
}

// MARK: - Subviews
private extension LargeView {
    var content: some View {
        ForEach(items) { item in
            ItemRow(item: item)
        }
    }
}

// MARK: - Actions
private extension LargeView {
    func loadItems() async {
        items = await store.fetchItems()
    }
}

Checklist

  • [ ] Properties ordered correctly (Environment → let → @State → computed → init → body)
  • [ ] Large body split into subviews or computed view properties
  • [ ] No unnecessary ViewModels introduced
  • [ ] Existing ViewModels are non-optional where possible
  • [ ] @Observable types stored as @State in root view
  • [ ] Dependencies injected via @Environment
  • [ ] File organized with MARK comments if >300 lines
  • [ ] Behavior unchanged unless explicitly requested

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.