What are the disadvantages of @Shared?

[hmhv]

I feel that @shared is very powerful, but are there any disadvantages?

If there are no major disadvantages, I think that from now on, almost all of TCA Reducer's State can be replaced with @shared(.inMemory..), what do you think?

[stephencelis]

@hmhv There are a few things that stand out:

• Mutating a shared value is less ergonomic (state.$property.withLock { $0 = newValue } vs. state.property = newValue) and also less efficient: a lock to this global, mutable state is required to provide exclusive access and avoid data races.

• @Shared observation is not minimal, unlike @Observable classes and @ObservableState in a TCA reducer. So you will see inefficient observation when you apply @Shared to large value types.

• There are also gotchas listed in the following article that note how @Shared values can't be Hashable or Codable: https://swiftpackageindex.com/pointfreeco/swift-sharing/main/documentation/sharing/gotchas

And beyond all that, the bottom line is @Shared values are reference-like (or reference-lite). While they wrap a value type that you can mostly treat like a value type, at the end of the day there is a reference under the hood and this is added complexity to be aware of.

So in general we would not recommend using @Shared unless you truly need to share or persist a value, and you should be careful of what you choose to share and persist when it comes to efficiency, observation and otherwise.

[bradhowes]

In terms of the @SharedReader with GRDB, my testing shows an interesting "feature" of having @SharedReader in reducer state: the shared queries will be executed if that reducer is pushed onto a StackState. This can be nice to keep states up-to-date, but it was surprising to me to see GRDB queries for my top-level view when I'm changing values in a child view.

Also, I had mistakenly "over shared" some state attributes and these attributes affected the GRDB query. This led to strange <bad decode in [%@]...> log messages and future inability to navigate deeper in the relationship. Removing the @shared attributes fixed that. I further tagged them with @ObservationStateIgnored as their effect on the view was entirely driven by the change in the query that they influenced.

[mbrandonw]

Also, I had mistakenly "over shared" some state attributes and these attributes affected the GRDB query. This led to strange <bad decode in [%@]...> log messages and future inability to navigate deeper in the relationship. Removing the @shared attributes fixed that.

The "bad decode" stuff usually only appears when the library emits purple runtime warnings and Xcode doesn't handle it properly. I find this happens most on old versions of Xcode.

I further tagged them with @ObservationStateIgnored as their effect on the view was entirely driven by the change in the query that they influenced.

This shouldn't be necessary. This is already what @ObservableState does for you:

https://github.com/pointfreeco/swift-composable-architecture/blob/48795d9064a11aeb66b8fa4a435992fb6f4abce4/Sources/ComposableArchitectureMacros/ObservableStateMacro.swift#L452-L460

[bradhowes]

@mbrandonw Thanks for responding. My Xcode is 16.2, and though I often got a purple message it was not always the case. Again, this happened when I had something like this:

  @ObservableState
  struct State: Equatable, Sendable {
    var path = StackState<Path.State>()
    @Shared(.appStorage("titleSort")) var titleSort: Ordering = .forward
    @SharedReader var allMovies: IdentifiedArrayOf<Movie>
  }

with titleSort adjusting allMovies though the reducer:

  private func updateQuery(_ state: State) -> Effect<Action> {
    let searchText = state.searchText.isEmpty ? nil : state.searchText
    let titleSort = state.titleSort
    let allMovies = state.$allMovies
    return .run { _ in
      do {
        try await allMovies.load(
          .fetch(
            AllMoviesQuery(ordering: titleSort.sortOrder, searchText: searchText),
            animation: .smooth
          )
        )
      } catch {
        reportIssue(error)
      }
    }
    .cancellable(id: "FromStateFeature.updateQuery", cancelInFlight: true)
  }

Again, with this coupling I got "bad decode" if I changed sort order via the titleSort property, drilled down into a child (movie), and then attempted to drill into an actor. Once I removed the @Shared designation on titleSort, the problem went away.

And so to your second point, yes using @ObservableState would be unnecessary due to the check in your macro, but I was not using it then. I am using it now more as a reminder to myself that titleSort affects views through its influence on allMovies; I doubt it has any meaningful impact performance-wise.