ViewStores as Services.

[enuance]

I really love how State, Actions, and Reducers allow you to model things in an exhaustive manner. The way I see it TCA seems to be very focused on producing output for SwiftUI to consume through Observable Object and so forth. But I think it would work quite well for modeling things as a non-view based service as well. What if I'd like to model business logic that operates on state and delivers it's output without the assumption of a view to consume it (a headless/viewless ViewStore for example). The way I see it is my inputs are the Store send actions, the output is the Store publisher, and if everything else remains the same (State, Action, Env, Reducer) I'd essentially have something like a micro service. Is there any reason why I couldn't use a ViewStore on a "non-View" thread so long as it's on a single synchronous thread?

I've created somewhat of a prototype that seems to work well. Essentially I have an iOS app that uses TCA normally, but then I've wrapped parts of an in-house SDK in a separate TCA ViewStore (without a View), which for disambiguation I'll call a ServiceStore. Then I inject the ServiceStores publisher as an AnyPublisher in the Application's RootEnvironment where it eventually get's subscribed to by one of the Application's scoped down Stores. I also injected the ServiceStore's send actions as closures in the Env. Being that they both operate on the Main queue I find that sometimes sending an action to the ServiceStore from an Application ViewStore triggers the assertion within the send method (file: Store.swift > send(_:)) unless I wrap the call to send in a .fireAndForget.

The ServiceStore and the ViewStore are completely separate and communicate through the ViewStore's env. I think this assertion is triggered because they are both operating on the same thread (main queue) and that the send to the ServiceStore triggers work that sometime happens without any delay that gets delivered back to the ViewStore. The fireAndForget reliably resolves this. Also there are aspects of the in-house SDK that I'm trying to wrap where the operations are expected to be on a non-main queue, which brings me to the following inquiries.

I really enjoy using TCA and would like to model a service in it that can be consumed by an iOS app. Are there any reasons why I should or should not do this? Also is there any documentation for setting up and operating a ViewStore on a synchronous, but non-main queue? Please feel free to let me know if I'm way out in left field and shouldn't be doing things this way.

[hibernat]

I just learn TCA, and ViewStore is one of my concerns. ViewStore keeps a copy (!) of the Store.state, and also subscribes to it, so any change in Store.state is immediately propagated to ViewStore.state. This subscription is done on thread (dispatch queue) where the ViewStore initializer is called. Also, ViewStore sends actions to Store.

So, my understanding is, that you can run all the ViewStore on any queue (thread), but it must be the thread where you have created the ViewStore, AND, it must be the queue (thread) where the Store is operated. This seems to be easy, but do not forget on environment used in the Store, that now will be called from non-main thread. Also effects should publish actions on the correct queue.

Please, correct me, if I am wrong, it helps me in my understanding TCA... :)

[lukeredpath]

TCA deliberately avoids taking an opinion on concurrency, other than to say that you should only use a store from a single thread/queue.

Trying to use TCA across different queues is likely to be a recipe for confusion and weird bugs and is best avoided.

There's really no need to use TCA in this way - because effects are based on Combine publishers you can implement effects that offload their work to background queues fairly trivially as long as you remember to use receive(on:) before you publish a new action.

[enuance]

Interesting. Its makes sense that we're able to offload heavy computations to a background queue through the Publisher's scheduler and receive its result on the main queue within the reducer before it touches state. I guess what I'm trying to say is what if that heavy (longer lived than usual) computation has it's own state that get's manipulated and produces new results based on that manipulation. And what if I'd like to model that state and computation in the form of a TCA Store/State/Action/Reducer set but in a different single synchronous queue. Couldn't this separate Store be theoretically injected into another Environment where it gets called and it sends updates? Supposed I'd like to model a networking client that caches things like tokens and other identifiers on State within some background TCA ServiceStore. I'm not quite sure but perhaps I've found a TCA hammer and I'm wondering if I could use it to build non-view based things like networking clients, communication SDKs, and other State driven systems where views are not (at least immediately) the intended consumer.

[lukeredpath]

Theoretically yes you could section off an entire part of your state in its own isolated store and provide an entry point for other stores to interface with it using the Environment, I’m just not sure what benefit you’d get from it.

TCA is intended to be composable. Segregating state seems counter to that notion. Building components that you can compose with the rest of your app state is one of the best things about TCA.

For pure services like API clients I think trying to use TCA to manage the internal state of that service implementation in isolation is over engineering.

[enuance]

Thank you so much for your perspective. I guess it really comes down to the notion of a "pure service" when it comes to segregating state. I agree that if the State truly is part of an application then it probably should be a participant in the composition of it rather than a segregated piece that is then injected into the environment as a Store (or some other interface) for interaction. Drawing the line of "should be a part of" vs "should be separate" may also be a fuzzy line to figure out. But supposed I had a pure isolated service like an API Client why would it be over engineering it to use TCA to manage its internal state? In the TCA SwiftUI Case Studies there's an entire domain dedicated to a CounterState with a single Int property called count and a reducer that either increments or decrements it. While I feel composability is definitely an excellent advantage of having such a domain I also feel that the deterministic behavior revolving around such state is just as much of an advantage if not more when it comes to managing state in services. To me, I think if we're willing to build a domain around a single Int then using a domain (or domains, not ruling out composability in these services) to manage a networking client wouldn't be out of line.