Housekeep/main actor data cache

[jmarek41]

Data cache on main actor -> prevent actor hops when reading/writing the changes from main actor

@samoilyk @bezoadam 👇 (part of Documentation.md)

Observation granularity: @Observable tracks at the stored property level. DataCache has one stored property — value. All computed properties that read dataCache.value (regardless of which sub-property) re-evaluate when any part of the model changes. For SwiftUI views this is fine — body re-evaluation is cheap and SwiftUI diffs the output. For imperative subscriptions, add manual deduplication or use Observations + .removeDuplicates() on iOS 26+.

[ssestak]

Template encourages one-shot assignment

The ExampleComponentModel template only shows a comment inside onAppear, which nudges developers toward:

func onAppear() async {                                                                                                                                                                                            
   items = dataCache.value.items                                                                                                                                                                                  }

This is a one-time copy. If a modal adds/modifies an item in the cache, the original screen won't reflect the change.

Computed properties should be the primary pattern

var items: [Item] { dataCache.value.items }

@Observable tracks reads through the entire chain — SwiftUI views reading this computed property automatically re-evaluate when dataCache.value changes. No manual subscription needed.

Suggestion: The template and Documentation.md should show computed properties as the primary usage pattern, with onAppear reserved for one-time setup/fetching.

Documentation hierarchy for observation patterns

The documentation covers three observation approaches but could benefit from a clearer hierarchy with concrete use cases:

1. Computed properties (display) — primary pattern for 95%+ of cases. Currently missing from the template and docs as an explicit best practice example.
2. withObservationTracking (imperative side effects) — correctly documented, but would benefit from a concrete use case, e.g. triggering a network re-fetch when a related cache value changes, firing an analytics
   event on state transition, or performing navigation based on cache state.
3. Observations + removeDuplicates() (iOS 26+) — good to have for completeness as a future replacement for the manual withObservationTracking loop.

Populate breaking change

T.Element now requires Identifiable (was just Equatable), and merging is now ID-based (update in-place + append). Better behavior, but this is a breaking change worth calling out in the PR description.

[jmarek41]

@ssestak I updated the template and docs. I'll also mention breaking changes in release notes.

The base branch was changed.