Read Only Shared State

[mhayes853]

I'm happy to say that so far I have had a smooth transition to @Shared in one of my projects. It cleaned up a very complex solution I had before to achieve the same functionality with a custom persistence client and custom reducer operator for synchronizing the data. However, during this process, I and some others have seemingly noted a particular kind of shared state that is read-only. After some brainstorming, I think it would be best if the library could provide better tooling for representing this kind of shared state.

In particular, I have noticed 2 kinds of shared state:

1. State which is mutated by a single or small handful of reducers, and is read-only to a larger pool of other reducers.

• Preferences, other mutable data owned by the app, etc.

2. State which is owned entirely by some external system, and has no business being mutated directly in a reducer at all.

• @Query in swift-data, GRDB value observations, the current user's location, etc.

I think number 1 tends to be the more common case, but number 2 in my opinion is far more interesting since I believe the current shared state tools would add some unnecessary overhead in implementing it. Therefore, I want to focus most of this on number 2, but what I have in mind should work for both cases.

So utilizing the current tools for number 2, assuming that we have some kind of PersistenceKey conformance that behaves like @Query in swift-data, and that we have some conversion process from @Model to value types. Then the following would be quite non-sensical:

struct Event: Hashable, Sendable, SwiftDataModelConvertible {
  var name: String
  // ...
}

extension PersistenceKey where Self == SwiftDataQueryKey<Event> {
  static var eventsQuery: Self {
    query(filter: #Predicate<Event.Model> { $0.title.contains("test") })
  }
}

@Reducer
struct Feature {
  @ObservableState
  struct State {
    @Shared(.eventsQuery) var events: [Event] = []
  }

  enum Action {
    case generateEventButtonTapped
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
        case .generateEventButtonTapped:
          // 🔴 There are now events in the array that don't match the query.
          state.events.append(Event(name: "invalid"))
          return .none
      }
    }
  }
}

This case would mirror why @Query is read-only in swift data. In this case, the reducer, or rather any reducer for that matter, has no business mutating the array of events since it could add an invalid event that wouldn't represent the query in @Shared.

For the point on mutations, since @Shared already allows mutations to its value, so we'll need a new property wrapper that prevents mutations to its value. A good name for this would be @External since it would represent a value that's strictly external to the reducer. @External would have a similar overload as @Shared with PersistenceKey, so that should cover the first case of shared state that I mentioned where a small handful of reducers can mutate the state whilst others can only read the state.

struct FeatureState {
  @External(.appStorage("count")) var count = 0
 
  mutating func increment() {
    self.value += 1 // ✅ Compiler Error: Left side of mutating operator isn't mutable: 'count' is a get-only property
  }
}

However, on the topic of PersistenceKeys, the hypothetical @Query-like persistence key entirely controls the state of the query. PersistenceKey has some protocol requirements that introduce unnecessary overhead in implementing these kinds of read-only persistence keys, mainly due to the save method and the optional Value associated type. A new protocol for read-only persistence keys would be ideal, something like:

public protocol ExternalKey<Value>: Hashable {
    associatedtype Value
    associatedtype Updates: AsyncSequence where Updates.Element == Value
 
    /// Loads the current value from the external storage.
    func load() -> Value

    /// An async sequence that emits when the external storage is changed from the outisde.
    var updates: Updates { get }
  }

The main thing here besides the lack of a save method, is unlike PersistenceKey load and updates don't deal with an optional Value. This is because in theory there should be a sensible default that is entirely controlled by the external system, like an empty array of events if none could be found from the query in the earlier example.

Using this protocol, there could then be an overload init of @External that allows for the usage of ExternalKey like:

extension External {
  public init(_ externalKey: some ExternalKey<Value>) {
    let initialValue = externalKey.load()
    // Use the initial value as the default...
  }
}

Then, this would change the query example from before to:

@Reducer
struct Feature {
  @ObservableState
  struct State {
    // The default value can be inferred by the init overload with ExternalKey
    @External(.eventsQuery) var events
  }

  enum Action {
    case generateEventButtonTapped
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
        case .generateEventButtonTapped:
          // ✅ Compiler Error: Cannot use mutating member on immutable value: 'events' is a get-only property
          state.events.append(Event(name: "invalid"))
          return .none
      }
    }
  }
}

Overall, I'm enjoying using @Shared, and I see a lot of parallels with the shared state tools, and useSyncExternalStore from the react world. As such I modeled the ExternalKey protocol similarly to the function parameters of useSyncExternalStore.

[scogeo]

+1 for this idea of read-only persistent external state. I haven't had a chance to play with the shared state beta yet, but this is exactly the use case (emulating SwiftData @Query) that I was going to experiment with in my application.

While, it is not entirely true that the Reducers don't modify the underlying state. I certainly do make changes to the underlying persistent data in some of my Reducers. However, I don't try to mutate the IdentifiedArray that typically holds the result of a query. For example, if I add a new Event to the underlying database in the Reducer, I don't accomplish this by mutating the IdentifiedArray of Events. That is because I would have to apply the same set of filters, sort ordering, etc. that is being handled by the underlying query. So I would have to duplicate that logic in my Reducer to know where to properly insert it.

So instead, the underlying datastore is modified through its own dependency, and the IdentifiedArray is eventually updated using an AsyncSequence when the change is observed in the persistent store.