Sharing state from an API throughout multiple parts of an app

[br-dev]

I'm currently working on a stock market iPad/iPhone app. I mention stock market specifically because I feel like I have a problem that I just can't seem to wrap my head around. I'm new to Composable Architecture, but not necessarily new to SwiftUI. I've been thinking about this for days, and I'm at the point where I think I may actually be overthinking it.

The issue is that I have 2 recurring API calls that fetch current market hours as well as a list of stock quotes. Currently, I use the API as a service dependency, and in my Root level state, I have a couple actions with a timer that simply fetch market data (hours and quotes) every 3 seconds.

From the root level, I think store all this information in an array of quotes and market hours in the RootState. Because it is also an iPad app, the way the layout looks is that both the Detail sidebar and the Content views show quote information, much like the Apple Stock app (think left table view has list of users Watchlist with stock information updating, and the Content view shows the stock details, along with the quote information + much more). Even when a user selects a Stock in the Detail view, the Detail view remains active and hence the remain stock quotes should also be updated for the stocks the user hasn't selected.

So for today, I simply use the Shared State example in the Case-Studies to pass down this quote information at every child view of the root view that requires it. Basically using computed variables for child states, and copying the quotes and market hours down the child states that need them. This seems like a ton of boilerplate, and as my app grows and this basic level stock quote information is needed in more and more places, its seems incredible redundant to use computed variables in this way.

Is there a better way? I've seen some suggestions of using Environment to share state throughout multiple parts of the app, but I haven't found any good examples of this.

The other problem that I have now run into, is that because these quotes are being fetched more frequently, SwiftUI is updating many many views in the hierarchy each time quotes are updated. I'm playing around with "observe" and trying to get everything scoped correctly, but I haven't quite figured out the right balance yet.

I may just be overthinking this, or maybe I haven't designed my various states correctly just yet (as I'm new to Composable Architecture), but any pointers you may be able to share would be greatly appreciated.

[rcarver]

Here's a pattern I often use to coordinate child domains with shared state without having to pass it down every level. With @Dependency, creating and sharing clients is lightweight so I'll just make a client supporting a given feature.

Just an example of the idea, not at all tested.

/// This client relays data from root to any child
struct FeatureClient {
    var updateValue: (Value) await -> Void
    var observeValue: () -> AsyncStream<Value>
}

struct RootFeature: ReducerProtocol {
    struct State {
    }
    enum Action {
        case task
    }
    @Dependency(\.stocksClient) var stocksClient
    @Dependency(\.featureClient) var featureClient
    func reduce() -> Effect {
        switch action {
        case .task:
            return .run { _ in
                // observe stocks and relay to FeatureClient
                for await value in stocksClient.observeStocks() {
                    await self.featureClient.updateValue(value)
                }
            }
        }
    }
}

struct ChildFeature: ReducerProtocol {
    struct State {
        var value: Value?
    }
    enum Action {
        case task
        case valueResponse(Value)
    }
    @Dependency(\.featureClient) var featureClient
    func reduce() -> Effect {
        switch action {
        case .valueResponse(let value):
            state.value = value
            return .none
        case .task:
            return .run { send in
                // Child observes shared state
                for await value in featureClient.observeValue() {
                    await send(.valueResponse(value))
                }
            }
        }
    }
}

[br-dev]

That is really clever. I'm curious if this would still be accepted within the bounds of the Composable Architecture. I wouldn't see why not given that the environment now holds the single source of truth, but I'm curious if there is an opinion on this.

It seems to even have the added benefit that the child who observes could transform the quote or market information into their own state instead of having to take everything. I will definitely try this out. Appreciate you taking the time to respond.

[Alex293]

IIUC @rcarver solution keep the source of truth in the parent state, the environment is just a shortcut to keep the child copy of the state in sync.

[rcarver]

That's right. The root reducer could transform it before sending to FeatureClient as well.

Sometimes I'll combine this approach with directly sharing state to a child of a child, where there's a tighter coupling between those two domains.

[tylerjames]

Hmm, this is interesting.

I've been thinking through a similar problem but with the added condition that the remote state is mutable from API calls made by the app.

Continuing with the stocks example, say you could create bundles of stocks and give the bundle a name. And then you could perform basic CRUD like list all your bundles, augment them, delete them, change the name etc.

So some small child feature might let you change the name of you bundle of stocks. That change would be made through an API call in a small feature client. But then you'd want the global-level environment client to "pull" down the list of stock bundles so that anywhere in the app you view stock bundles the name change would be reflected.

Is there some way expand @rcarver 's solution to work this way? Like maybe the global client environment acts as a repository and all feature clients are kind of carved off of this bigger client?

And how to make the global client know that a feature client has made an API call that changes the remote state?

[rcarver]

Lots of questions in here, but similarly I'd create a domain specific client. Here's the simplest form it might take.

struct StockBundlesClient {
    var createStockBundle: (StockBundle) async -> Void
    var updateStockBundle: (StockBundle) await -> Void
    var observeStockBundles: () -> AsyncStream<[StockBundle]>
}

Features can use this client to observe or modify state. The live implementation of the client would handle storage, whether that's to a remote API or locally. If it's a remote API then would the client push out new data before it's confirmed remotely? Is there a persistent listener to the remote API? All of that could change as it's hidden behind the client.

[tylerjames]

I think the observeStockBundles is nice because that observable could be handed to the stock client by the global client.

I guess the tricker part is figuring out how the global client should know that a feature client made mutation to the remote state so the global client knows to fetch the remote state again.

[rcarver]

Not sure I'd lean on this global/local client pairing too much. Instead, call the 'global' client/API from the feature client. The bigger idea for me is that feature clients can expose a very simple surface area for a whole tree of small domains.

[br-dev]

Just to give everyone a quick update, based on @rcarver's answer I was able to get something working by doing the following.

First I created a SharedFeature generic class which can be reused for any shared variable through the app:

class SharedFeature<T: Equatable> {
    @Published var updateValue: T?

    private var cancelBag = Set<AnyCancellable>()

    var observedValue: AsyncStream<T> {
        AsyncStream { continuation in
            self.$updateValue.sink { value in
                if let v = value {
                    continuation.yield(v)
                }
            }
            .store(in: &self.cancelBag)
        }
    }
}

Then I setup my dependencies:

extension DependencyValues {
    var quoteClient: SharedFeature<[Quote]> {
        get { self[StockQuoteClient.self] }
        set { self[StockQuoteClient.self] = newValue }
    }

    var marketHoursClient: SharedFeature<MarketHours> {
        get { self[MarketHoursClient.self] }
        set { self[MarketHoursClient.self] = newValue }
    }
}

class StockQuoteClient: DependencyKey {
    static let liveValue = SharedFeature<[Quote]>()
}

class MarketHoursClient: DependencyKey {
    static let liveValue = SharedFeature<MarketHours>()
}

Then in my RootState reducer:

@Dependency(\.quoteClient) var stockQuoteClient
@Dependency(\.marketHoursClient) var marketHoursClient

....

case .subscribeQuotes:
    return .run { send in
        for await quotes in stockQuoteClient.observedValue {
            await send(.updateQuotes(quotes))
        }
    }

case .updateQuotes(let quotes):
    state.marketStockQuotes = quotes
    return .none

case .subscribeMarketHours:
    return .run { send in
        for await marketHours in marketHoursClient.observedValue {
            await send(.updateMarketHours(marketHours))
        }
    }

case .updateMarketHours(let marketHours):
    state.marketHours = marketHours
    return .none

Not shown here but in my reducer I also have a case which updates the stockQuoteClient.updateValue into the main environment state which is what the subscribers are subscribing too.

I've then been able to do this through multiple layers of subviews and it has worked very nicely.

I still need to figure out when/how I should cancel my subscriptions, but I think that is relatively minor.

Thanks @rcarver for the suggestion, so far this works pretty well. Hopefully others find this useful as well.

[br-dev]

@tgrapperon, really appreciate that. I was fumbling a little bit on how exactly I should do cancellation, your answer helps a lot. Also, I didn't know about the second solution on iOS 15+, thanks again!

[rcarver]

oh nice @tgrapperon I didn't know about that initializer. Looks like it's actually this? Not the block variant?

AsyncStream(self.$updateValue.compactMap { $0 }.values)

Here's a client I just wrote, now adopting this style. Any gotchas in here?

public struct VesperOnboardingClient {
    var sendAction: (VesperOnboardingAction) async -> Void
    var observeActions: () async -> AsyncStream<VesperOnboardingAction>
}

extension VesperOnboardingClient: DependencyKey {
    public static let liveValue: Self = {
        let subject = PassthroughSubject<VesperOnboardingAction, Never>()
        return .init(
            sendAction: { subject.send($0) },
            observeActions: { AsyncStream(subject.values) }
        )
    }()
    public static let previewValue = Self(
        sendAction: { _ in },
        observeActions: { .never }
    )
    public static let testValue = Self(
        sendAction: XCTUnimplemented("\(Self.self).sendAction"),
        observeActions: XCTUnimplemented("\(Self.self).observeActions", placeholder: .never)
    )
}

[tgrapperon]

@rcarver Indeed, you're right about the init, I mixed up with another thing.
Your onboarding client seems OK, but I would make it Sendable (which will imply to make both closures @Sendable). I would also think about making the observeActions a sync closure of AsyncStream, which should be a little more convenient to use because you won't have to await for the sequence to start enumerating it.

As an aside, you can always make an async AsyncSequence iterate more or less like a sync AsyncSequence if you coalesce awaiting for the sequence with awaiting for its first element. You can for example define the following AsyncStream extension to transform an async AsyncSequence into a sync AsyncStream:

extension AsyncStream {
  public init<S: AsyncSequence>(_ sequence: @escaping () async -> S) where S.Element == Element {
    var iterator: S.AsyncIterator?
    self.init {
      if iterator == nil {
        iterator = await sequence().makeAsyncIterator()
      }
      return try? await iterator?.next()
    }
  }
}

You won't need such extension in your example, but it shows that the transform is always possible.

[rcarver]

Thanks for the notes @tgrapperon!

public struct VesperOnboardingClient: Sendable {
    public var sendEvent: @Sendable (VesperOnboardingEvent) async -> Void
    public var observeEvents: @Sendable () -> AsyncStream<VesperOnboardingEvent>
}

I don't quite follow your aside, when would such a transformation be useful?

[tgrapperon]

@rcarver No, it was just a demonstration that you can always extract a sync AsyncSequence from an async AsyncSequence. You don't need it in your case, but the situation may present itself if the subject is an actor for example. You would have to await for the sequence itself before returning it, and this extension would allow to erase this requirement from the API's side of your dependency.