Optimizing Event Filtering and View Updates in SwiftData

Below is one approach that others have found effective when a computed property is doing heavy work on every view update.

The Problem

Currently your computed property (used inside ForEach) is re‑evaluated every time anything in the view changes—even if the underlying events haven’t changed. This forces the filter and sorting functions to run many times. If filtering/sorting is heavy (for example because of on‑the‑fly distance calculations) then you run into performance issues and even crashes.

The Recommended Solution

Instead of making your dataset a computed property, compute it once and store it in a state variable. Then update that variable only when the events array (or one of the filter criteria) changes. For example, you might:

1. Declare a @State variable (or use an async task/Combine publisher if needed) for the processed data.
2. Use an onChange modifier (or onReceive) to update that state whenever the underlying events or filter parameters change.
3. Use the stored results in your ForEach so that the expensive filtering/sorting logic is not repeatedly recalculated during every renders.

Example

Suppose you have something like this in your view:

SWIFTCopied
@Query(sort: \Event.startTime) private var events: [Event]
@State private var processedData: [Date: [Event]] = [:]

var body: some View {
    List {
        ForEach(processedData.keys.sorted(), id: \.self) { day in
            Section(header: Text(day, style: .date)) {
                ForEach(processedData[day] ?? []) { event in
                    NavigationLink {
                        EventEditor(event: event)
                    } label: {
                        EventRow(event: event)
                    }
                    .swipeActions {
                        Button(role: .destructive) {
                            eventData.delete(event)
                        } label: {
                            Label("Delete", systemImage: "trash")
                        }
                    }
                }
            }
        }
    }
    .onChange(of: events) { newEvents in
        updateProcessedData(with: newEvents)
    }
    .onChange(of: filterManager.filterParameters) { _ in
        updateProcessedData(with: events)
    }
}

And then define a helper method to update your processed data:

SWIFTCopied
func updateProcessedData(with events: [Event]) {
    // First, filter your events.
    let filtered = filterManager.filteredEvents(events: events)
    // Then, sort them by day.
    processedData = filterManager.sortedEventsByDay(events: filtered)
}

Benefits

• Single Calculation: The expensive operations happen once per change (through onChange) rather than on every view recomputation.
• Clear Dependency: You update only when the query results or filter parameters change.
• Better Performance: The UI is rendered using a cached result that doesn’t recalc in the middle of a render pass, helping to avoid stalling or crashes on older devices.

Additional Considerations

• Debouncing: If filter parameters (like search text) change frequently, you might add some debouncing (with Combine or Task.sleep) before triggering the update.
• Background Queue: If even the one‑time calculation is heavy, consider moving the work off the main thread and then updating the UI on the main thread when done.

By caching the processed data, you avoid heavy compute in your view’s body. This pattern is common in SwiftUI when a computed property is too expensive to evaluate every time the view updates.

Using this approach should help you render only once per event update and avoid the “bad range” error that signals that data is being modified during rendering.