Working with a common state throughout the app

[Paul-Svetlichny]

Hey guys! I've read a lot of articles and seen (and partially adapted into my test project) the Shared State example, but still can't wrap the concept around my head.
In our application we have a lot of properties, which needs to be stored and updated during the whole application lifecycle from external repositories based on different actions in the app.
For simplicity, let's say we have a score property in the Main App state.
So we have it like this

struct AppReducer: ReducerProtocol {
    private enum TimerID {}

    struct State: Equatable {
        var score = 0
        
        var profile: ProfileReducer.State {
            get {
                ProfileReducer.State(
                    score: self.score
                )
            }
            set {
                self.score = newValue.score
            }
        }
    }
    
    enum Action {
        case appDelegate(AppDelegateReducer.Action)
        case profile(ProfileReducer.Action)
        case changeScore
    }
    
    var body: some ReducerProtocol<State, Action>  {
        Scope(state: \.profile, action: /Action.profile) {
            ProfileReducer()
        }

        Reduce { state, action in
            switch action {
            case .appDelegate:
                let clock = ContinuousClock()
                return .run { sender in
                    while !Task.isCancelled{
                        do{
                            try await clock.sleep(for: .seconds(1))
                            await sender.send(.changeScore)
                        }
                        catch{
                            if !Task.isCancelled{fatalError()}
                        }
                    }
                }
                .cancellable(id: TimerID.self,cancelInFlight: true)
            case .changeScore:
                state.score = Int.random(in: 0...100)
                return .none
            case .profile:
                return .none
            }
        }
    }
}

What it does, it just imitates score update from external repository by randomly updating score as soon as application is launched.
And we have a Profile screen, which shows the score along with other user data, so for now it looks like this (user data is ignored):

struct ProfileReducer: ReducerProtocol {
    func reduce(into state: inout State, action: Action) -> ComposableArchitecture.EffectTask<Action> {
        
    }

    struct State: Equatable {
        var score = 0
    }
    
    enum Action {}
}

So there are a couple of questions finally :)
First of all, as far as I understand, each time the main app state is updated, all the child states, including Profile.State in the example above, will be recreated with default values and then Profile.State will be updated based on getter. In that case, how to maintain local child state properties?
For example, we have score as a property, which was stored in the main app state, but we want to add local properties to Profile state, which will be held only there and not synced to the main state, something that is View-dependant and only reflects user interactions. Like if we have paging on the Profile screen and a property currentPage, which tracks current user progress on that screen, but doesn't need to be stored globally.

How to add that property to "local" child state and maintain it when the global state is changed and child state is recreated?

Another related question is what is the best way to update that parent state from the child one, for example, we have user data (mentioned above but not in the code example), which is part of the parent state and is passed to the child state. If it is modified in the child view (e.g. Profile), how to correctly update this data in the parent state?

And finally (for now 😄) how to handle internal interactions, when there is a property to trigger animation and a button, which triggers that property. What is the proper way of handling this? Should we put this property into a state and update it with action? Or can we use an action to update that property without being part of the state?

@State var shouldAnimate = false
...
.animation(.easeInOut(duration: 6), value: shouldAnimate)
...
Button("Animate") {
    shouldAnimate.toggle()
}

I know these questions are noobs' ones, but I'm reading documentation and looking at different example for the last several days, and still can't wrap it up. I will really appreciate your help!

Have a great day!

[andwrobs]

hi @Paul-Svetlichny , have you had a chance to check out the video series tour available for this framework? they break down how to work with the framework from first principals and Swift programming know-how. there are also case studies that show end-to-end how to do a few of the things you asked here. hope that helps!

[Paul-Svetlichny]

I did have, but haven't checked all of the videos as the tour is 27 hours long. I will appreciate if you could point out some specific videos that mentions the problem.
I've also checked case studies and the current example above is based on Shared State case study, and the case raised additional questions, which I've asked in the original post.
I understand that my questions can be newbie-ish and looking like a search for a shortcut, but I'm trying to figure out how to do things correctly with help of videos and case studies for the last several days already, and asking here was not the first thing I've tried ;)

[andwrobs]

to supplement the answers below, check out these videos:

• Dependencies
  https://www.pointfree.co/collections/composable-architecture/reducer-protocol/ep205-reducer-protocol-dependencies-part-1
• Sendable and Actors
  https://www.pointfree.co/collections/concurrency/threads-queues-and-tasks/ep193-concurrency-s-future-sendable-and-actors

should help you design & implement dependencies that expose endpoints to your shared state.

cheers!

[Paul-Svetlichny]

We already have dependencies implemented and we do have them implemented in our current architecture like that by subscribing to each publisher (to a bunch of them, actually) in different places, and it is kind of frustrating to put similar code in all the places, where we need data fetched from a repository.
I hoped that this can be improved by using Parent State as kind of a Data Layer, which has all the app's data, required to build each view's state at any time. And in order to pass data to a view we just pass a slice of the parent's state, which sounds really simple.
Thank you for links, I will review them and check if I've missed something!

[andwrobs]

@Paul-Svetlichny, i read your follow-up below.

how i might do it:

you could wrap WS connection in an AsyncStream and then expose that as an endpoint, see this example

1 location for all the handler code associated with updates from your data repository.

each child view/feature imports the dependency @Dependency(\.dataRepository) var dataRepo: DataRepository

and can tap into updates to the data repository by kicking off an await'd event loop, e.g.:

    case .task:
      return .run(priority: .background) { send in
        for await dataRepoUpdate in await dataRepo.listen() {
          /// either send an event back into system
          await send(.dataRepoUpdate)
          
          /// or update an actor cache
          await dataRepo.updateCache(dataRepoUpdate)
        }
      }

[Paul-Svetlichny]

Thank you!
Will take a closer look at the example provided. I think I understand the idea.

[tgrapperon]

Hey @Paul-Svetlichny
I'll try to respond to a few of your questions, but I'm a little in a hurry, so sorry if I miss some of them.

When you have some internal properties that you want to preserve, one solution is to use some private storage that you use to persist the data. For example if your Profile.State is:

struct Profile.State {
  var score: Int
  var currentPage: Int
}

you can "save" the currentPage value like this:

struct Parent.State {
  var score: Int

  private var _profile: Profile.State = .init(score: 0, currentPage: 0)
  var profile: Profile.State {
    get {
      var state = self._profile
      profile.score = self.score
      return state // A `Profile.State` with an updated `score`.
    }
    set {
      self._profile = newValue // "Save" the current `Profile.State` value
      self.score = newValue.score // Propagate the updated `score` to the parent.
    }
  }
}

From your reducer/store, you interact only with profile, but _profile provides a home for internal properties. This also updates the parent state. This boilerplate would probably be improved with the upcoming macros in Swift.

About your last question, I'm not 100% sure to follow, but if it boils down to "should this be put in TCA or in SwiftUI", I'm usually using testability to decide: if this is something that I may want to write a test for, it should probably go in TCA. Otherwise, it can go in SwiftUI. In your example, if you want to store the shouldAnimate flag in your View, this is fine, as long as this is not interacting with the effective State of TCA. For example, if this value would be a user setting, it should then probably go in TCA. If you want to control the animation depending on some subtle rules, you can also put it in TCA where it can be easier to decide, but you can also expose enough information to decide in the View. I don't know if I'm clear, but to rephrase: you don't need to put everything in TCA, especially if you won't write a test for it, and it is fine to have transient values stored on the View layer.

I hope it helps. Feel free to let me know if something was not clear.

[Paul-Svetlichny]

Thanks @tgrapperon! I'll see how it can be applied to our case.
Very useful example!

[mbrandonw]

Everything @tgrapperon mentioned above is correct and worth considering, but I just want to add one more clarification about "shared state."

Our shared state case study is really only meant for a specific kind of shared state, and that is the kind that does not travel very far. It does handle the situations you asked about (child updating parent, parent updating child, etc.), but because of the boilerplate involved it's really only appropriate if you need to share a small bit of state with a small number of views.

For shared state that is ubiquitous and should be available in every corner of the app you need different techniques. Such shared state is really not even distinguishable from user defaults, or data on the disk, or data in a database. As such, it's appropriate to treat that kind of "shared" state as a dependency.

It can be a simple client that exposes some properties for reading/writing data to the shared state, and it can expose endpoints for subscribing to state changes (done via effects). Under the hood it can persist the data however it sees fit, e.g. user defaults, saving to disk, saving to SQLite, etc.

[mbrandonw]

It sounds like you want something where you have deeply nested state such that each layer holds onto a piece of shared state:

struct Feature1 {
  // Other fields
  var feature2: Feature2
  var shared: SharedState
}
struct Feature2 {
  // Other fields
  var feature3: Feature3
  var shared: SharedState
}
struct Feature3 {
  // Other fields
  var shared: SharedState
}
// ...

…and such that all of the shared states are synchronized across so that any change to shared in one feature is instantly made to all other features.

While you can accomplish this using the techniques from the shared state case study, it does come with some boilerplate, and I don't think it's particularly ergonomic. And this isn't a TCA issue, this would be a problem in UIKit, vanilla SwiftUI, and really just any kind of framework or architecture.

SwiftUI tries to solve this problem with EnvironmentObject, but it has its drawbacks. If you don't setup an environment object properly you can crash your app, they can cause your view hierarchy to recompute too often if not careful, and of course it only works in the view layer. Not in ObservableObjects or other places that can make your code more testable.

In TCA I think the best way to solve this is to have a dependency client that holds onto the shared state, which makes the state immediately available to any feature that can do @Dependency(\.sharedState). The client might look something like this:

struct SharedStateClient {
  // A synchronous endpoint to immediately grab current state
  var value: () -> SharedState 

  // An asynchronous endpoint to update state, only should be called in effects.
  var setValue: (SharedState) async -> Void 

  // A publisher/async sequence of values to observe changes
  var values: () -> AsyncStream<SharedState>
}

Now this style also has its own drawbacks, but I think it's the pattern that works best in TCA for right now.

[ghost]

So just to be clear, if there are screens whose states contain a significant amount of overlapping, mutable data, the recommendation is to treat the shared state as a dependency? This seems to contradict the high-level overview from https://github.com/pointfreeco/swift-composable-architecture#what-is-the-composable-architecture :

...share state across many screens so that mutations in one screen can be immediately observed in another screen

(Or at least it seems contradictory if you assume state here means TCA state, not dependency state).

I agree it seems more practical to take the dependency approach. In our own work we've got too much code in our reducers just moving state changes up and down the navigation hierarchy.

But it's a long way from the top-level readme down to this discussion to find out that dependency might be the right tool for this, and I think many apps would be sharing a fair amount of state across screens.

[mbrandonw]

So just to be clear, if there are screens whose states contain a significant amount of overlapping, mutable data, the recommendation is to treat the shared state as a dependency?

Yes, that is the style we have found most effective.

This seems to contradict the high-level overview from https://github.com/pointfreeco/swift-composable-architecture#what-is-the-composable-architecture :

That bullet point has been in the readme since our first release nearly 3 years ago, and so probably could be updated a bit. I think the most important aspect of it is how TCA allows you to represent state with simple value types (in comparison to vanilla SwiftUI with ObservableObjects). And technically when multiple features are integrated together it is true that any changes a parent feature makes to state is instantly observed in every child feature. But, if we are talking about shared sibling state, then things are more nuanced. You can certainly do it at the state level, as shown in the case study, but that does come with the cost of boilerplate.

Really it sounds like to me that there is a gap in community knowledge to fill about state in TCA. The term "state" is not well-defined because it can be dependent on the complexity of the app. If you are trying to teach TCA to someone with no knowledge (as most of our docs do), then it's probably fine to just literally put everything in State structs because you can get pretty far that way.

But as the application grows in complexity you realize that some of your "state" is far more ubiquitous than other state, and is more similar to a database than something stored in memory for a feature. At that point it makes more sense to truly model it like you would a database, and throw it into a dependency.

That's a pretty advanced topic, and so hard to capture in a readme or basic docs. We certainly can (and will) add more advanced documentation for things like this, but it also sounds like a nice topic for someone in the community to blog about.

[bdhazman]

I've also struggled with handling state that is accessed from many different parts of an app and found your comment, @mbrandonw about SharedStateClient really interesting and helpful so thank you for that (and everything you guys do to build TCA!). What do you think is the best way to go about observing changes from a dependency (like SharedStateClient in features/reducers? Also, do you have any advice on designing an observable dependency that stores some state like SharedStateClient?

[takehilo]

@mbrandonw
I tried implementing SharedStateClient as follows.
Since AsyncStream cannot have multiple consumers, I achieved an AsyncStream that can handle multiple consumers by using CurrentValueSubject.
However, there is a problem with this implementation.
CurrentValueSubject is not Sendable, so it will cause an error in future Swift updates.
I would appreciate it if you could share any ideas for better implementations.

struct SharedStateClient {
    var value: @Sendable () -> SharedState
    var setValue: @Sendable (SharedState) -> Void
    var values: @Sendable () -> AsyncStream<SharedState>

    init(
        value: @Sendable @escaping () -> SharedState,
        setValue: @Sendable @escaping (SharedState) -> Void,
        values: @Sendable @escaping () -> AsyncStream<SharedState>
    ) {
        self.value = value
        self.setValue = setValue
        self.values = values
    }
}

extension SharedStateClient {
    static func live() -> Self {
        let subject = CurrentValueSubject<SharedState, Never>(.init(text: "first"))

        return .init(
            value: {
                subject.value
            },
            setValue: {
                subject.send($0)
            },
            values: {
                AsyncStream { continuation in
                    let cancellable = subject
                        .dropFirst()
                        .removeDuplicates()
                        .sink { value in
                            continuation.yield(value)
                    }

                    continuation.onTermination = { _ in
                        cancellable.cancel()
                    }
                }
            }
        )
    }
}

ref: https://forums.swift.org/t/asyncsequence-stream-version-of-passthroughsubject-or-currentvaluesubject/60395

[Paul-Svetlichny]

I will update my post a bit with what we've ended up with. It is a bit different (in terms of exact task) from how the topic started, because we've managed to avoid sharing that property so far, but we've encountered another related case and below is how we've managed to implement it so far.
In our application we have bottom tab bar, which is just a "container" view with buttons, switching the view in the top part of that container. And we have a Navigation Manager, which is separate and unrelated to that container thing. It doesn't know anything about that container view, it is only responsible for performing commands and updating the navigation stack.
The problem is that in order to switch tabs navigation manager has to know the currently selected tab and tabs at all, so we've done it in the following way.

struct NavigationStore {
    let store: StoreOf<HomeScreenContainer>
}

// MARK: Dependency

enum NavigationProviderKey: DependencyKey {
    static let liveValue: NavigationStore = NavigationStore(store: Store(initialState: HomeScreenContainer.State(), reducer: HomeScreenContainer()))
    static let testValue: NavigationStore = NavigationStore(store: Store(initialState: HomeScreenContainer.State(), reducer: HomeScreenContainer()))
}

extension DependencyValues {
    var navigationStore: NavigationStore {
        get { self[NavigationProviderKey.self] }
        set { self[NavigationProviderKey.self] = newValue }
    }
}

HomeScreenContainer has properties for current screen and the enum Tab { ... } which has all the tab cases.

struct HomeScreenContainer: ReducerProtocol {
    struct State: Equatable {
        enum Tab: Equatable {
            case tab1
            case tab2
            case tab3
        }

        let bottomBarHeight: CGFloat = 80
        var currentScreen: Tab = .tab1
    }
    
    enum Action: Equatable {
        case bottomBarPressedTab(State.Tab)
    }
    
    var body: some ReducerProtocol<State, Action> {
        Reduce { state, action in
            switch action {
            case let .bottomBarPressedTab(tab):
                state.currentScreen = tab
            }

            return .none
        }
    }
}

NavigationManager uses that store as a dependency, like this:

class AppNavigationManager: NavigationManager {
    @Dependency(\.navigationStore.store) var store

    func switchTabTo(tab: Tab) {
        ViewStore(navigationStore.store).send(.bottomBarPressedTab(tab))
    }
}

Also the container view itself uses the store the same way:

struct HomeScreenContainerView: View {
    @Dependency(\.navigationStore.store) var store

    var body: some View {
        WithViewStore(store, observe: { $0 }) { viewStore in
...

I'm not sure if this is the correct way of handling the situation, but it works so far and without a boilerplate code. Moreover we have several views depending on that navigationStore (like for example the bottom panel, which needs to know the currently selected tab).

[ratnesh-jain]

I came up with the similar solution but using SwiftUI's Environment that can be replaced by DependencyValues too.
Ref. to Toy project: https://github.com/ratnesh-jain/TCA-Shared-Reducer.

+ @Environment(\.playbackControlStore) private var playbackControlStore
...

CaseLet(/TabFeature.State.listen, action: TabFeature.Action.listen) { listenStore in
    NavigationStack {
        ListenView(store: listenStore)
            .safeAreaInset(edge: .bottom) {
+               PlaybackControlMiniView(store: playbackControlStore)
            }
    }
    .tabItem {
        Tab.listen.label
    }
}

[andwrobs]

Curious if there are any gotchas or things we should look out for when using this approach given an earlier response from Brandon:

SwiftUI tries to solve this problem with EnvironmentObject, but it has its drawbacks. If you don't setup an environment object properly you can crash your app, they can cause your view hierarchy to recompute too often if not careful

Seems like a great solution, but especially w.r.t. the point of view recomputing, I'm not sure which views would be affected when the dependency added here changes.

Thanks for sharing the approaches @ratnesh-jain and @Paul-Svetlichny

[ratnesh-jain]

Seems like a great solution, but especially w.r.t. the point of view recomputing, I'm not sure which views would be affected when the dependency added here changes.

@andwrobs Thanks for this really good question.

To find out, I added onAppear view modifier and _printChanges() function to identifiy the body re-computation behaviour when the environment property changes.

And it turns out the body is called every time, but due to WithViewStore its does not re-compute its child when unless the Reducer's state changed. This is what I found in the observation but not sure how the this body re-evaluatation and re-rendering is working internally. (may be @mbrandonw or some-one can confirm/correct 🤞)

I have made few changes to in toy project repo and updated the readme with some video documents.

[oliverfoggin]

Just to add to what has been said before.

For me, this was one of the biggest "lightbulb" moments in thinking about and using TCA.

I was struggling for a while to work out where all our app's data should live. Like where should the user be stored in TCA so that anywhere can get hold of it.

When we chnaged over to treating this shared data as a dependency it suddenly made thinking about TCA much easier.

[ihorvovk]

I've taken the NavigationStore idea of @Paul-Svetlichny and implemented a more general SharedStateStore with a unidirectional flow through its state, with a convenient extension for ReducerProtocol features. Below is an example, where the shared state contains only one property user. It provides a simple action to set the user.

struct SharedStateReducer: ReducerProtocol {
    
    struct State: Equatable {
        var user: User?
    }
    
    enum Action {
        case setUser(User)
    }
    
    func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
        switch action {
        case .setUser(let user):
            state.user = user
            return .none
        }
    }
}

struct SharedStateStore {
    
    let store = Store(initialState: .init(), reducer: SharedStateReducer())
}

extension SharedStateStore: DependencyKey {
    
    static let liveValue: SharedStateStore = SharedStateStore()
}

extension DependencyValues {

    var sharedState: SharedStateStore {
        get { self[SharedStateStore.self] }
        set { self[SharedStateStore.self] = newValue }
    }
}

The ReducerProtocol extension below provides functions for unidirectional flow of shared data through the shared state. subscribe - to sync a local feature state with the shared state. update - to update the shared state with a fresh data.

extension ReducerProtocol {
    
    func subscribe<T>(to store: StoreOf<SharedStateReducer>, keyPath: KeyPath<SharedStateReducer.State, T>, action: @escaping (T) -> Action) -> EffectTask<Action> {
        .run { send in
            let sharedStatePublisher = ViewStore(store).publisher
            for await value in sharedStatePublisher.values.map({ $0[keyPath: keyPath] }) {
                await send.send(action(value))
            }
        }.cancellable(id: keyPath)
    }
    
    func update(_ store: StoreOf<SharedStateReducer>, action: SharedStateReducer.Action) {
        ViewStore(store).send(action)
    }
}

And UserFeature shows how to sync its state with the shared state. In the onAppear action, we subscribe to changes to the user in the shared state, update the local state accordingly. And we also perform a call to load a fresh user. Once it is loaded, we invoke the update function from the extension to update the shared state. It will trigger the subscription in turn, and the local UserFeature state will update accordingly.

struct UserFeature: ReducerProtocol {
    
    struct State: Equatable {
        var user: User?
    }
    
    enum Action {
        case onAppear
        case updateUser(User?)
        case didLoadUser(Result<Void, Error>)
    }
    
    @Dependency(\.sharedState.store) private var sharedStateStore
    
    var body: some ReducerProtocol<State, Action> {
        Reduce { state, action in
            switch action {
            case .onAppear:
                return .merge(
                    subscribe(to: sharedStateStore, keyPath: \.user, action: Action.updateUser),
                    loadUser(state: &state)
                )
            case .updateUser(let user):
                state.user = user
                return .none
            case .didLoadUser(.success(let user)):
                return .fireAndForget { update(sharedStateStore, action: .setUser(user)) }
            case .didLoadUser(.failure):
                return .none
            }
        }
    }
}

private extension UserFeature {
    
    func loadUser(state: inout State) -> EffectTask<Action> {
        return .task {
            let user = User() // loading code
            return .didLoadUser(.success(user))
        } catch: { error in
            return .didLoadUser(.failure(error))
        }
    }
}

[ihorvovk]

Corrected. The shared state should be updated from an effect, not in the reducer.

[majelbstoat]

This is an interesting approach, thank you for the thorough writeup! Couple of questions:

• What makes this better/more ergonomic than just having a vanilla shared state client to hold the user, as outlined here?
• Why is state passed to the loadUser method? It doesn't appear to be used.
• We're about 6 months on from your example; are you still using it this way, and how have you found it to work in practice?

[mycroftcanner]

@mbrandonw Does it makes sense to use TCA inside of a dependency so that we can use a reducer and test the logic of that dependency easily? or is that an anti-pattern?

[mbrandonw]

I would say that typically no, you do not want to use TCA inside a dependency.

Ideally the dependencies do not have logic in them. Even complex dependencies, such as audio recorders, speech recognizers, etc. do not have significant logic in them. Just simple endpoints that are invoked and they call the underlying live dependency's code. What kind of dependency are you using that has such complex logic inside it that warrants a TCA feature?