RFC: Add Store.send and Store.withState

[stephencelis]

Ever since its introduction, the Composable Architecture has provided one way of accessing store state and sending store actions: through a ViewStore. The view store abstraction made a ton of sense at the time for SwiftUI, because we needed an object that could be observed in the view when state changes, and this object could not simply be the store itself, because stores typically contain much more state than its associated view needs to do its job, and this leads to unnecessary view computations and performance problems.

The view store is not a lightweight abstraction. It requires a noisy amount of code to create one, which has grown noisier over time, and poses ergonomic issues when you just want to send an action and no view store is available:

ViewStore(self.store, observe: { $0 }).send(action)

The act of creating a view store is also not lightweight: it sets up a Combine subscription for SwiftUI to observe.

To address these issues, we introduced an RFC earlier this year to lukewarm response: #1946

The solution didn’t seem to be quite right.

Well, now that WWDC23 has come and gone and we’ve taken the Observation framework for a spin, we have a much clearer picture of the future of TCA, so we’d like to propose some incremental steps we can take with the library to make it more ergonomic today, while keeping sight of the future.

🪦 R.I.P. ViewStore, 2020–2023

In particular, view stores are not long for this world. With Observability we can forgo the view store abstraction and simply access state directly on the store, and the view will track changes to the properties it accesses and re-render only when those properties change. And so it makes sense to also send actions directly to the store.

To prepare for this future we would like to introduce a couple changes that make the Composable Architecture a bit more lenient, and ergonomic, today:

Store.send

We will be adding a send method directly to the store so that you can send actions when a view store is not available. Rather than jumping through hoops to create and throw away a view store just to send an action, simply send the action directly to the store:

Button("Close") {
  // Before:
  ViewStore(self.store, observe: { $0 }).send(.closeButtonTapped)

  // After:
  self.store.send(.closeButtonTapped)
}

This admittedly muddies the waters a bit. There are now two ways to send actions to the store. Our recommendation is to prefer sending actions to view stores when they are available and fall back to sending actions to stores only when necessary. In the future world of Observability this muddiness gets cleaned up as the view store is retired.

Store.withState

We would also like to provide a lightweight way to access the current state of a store without the overhead of a view store.

store.withState { currentState in
  // Do something with the current state...
}

// Pluck the current count out of the store:
let count = store.withState(\.count)

Note that accessing state this way does not perform any observation at all. You are only getting a snapshot of state at a specific time, and if you do so in a SwiftUI view you should not expect the view to update when this state changes.

Future directions

These are two small steps towards to future, but there are obvious areas of the library to address.

Store.send vs. ViewStore.send

At the moment we are only adding a single Store.send method. There are many versions of ViewStore.send that layer on things like SwiftUI animation, async-await, etc. While we plan on surfacing this functionality on Store in the future, you can still access this functionality today on ViewStore.

UIKit View Stores

We have always felt that view stores were a bit forced onto UIKit, and they never fit quite as well. We reasoned that having a single unified way of interacting with state and actions made it worth it, but now that it’s all going away, it probably makes sense to distance the Composable Architecture’s UIKit integration from the view store concept entirely. Instead of creating a view store to access state, we could provide a .publisher directly on Store, and allow folks to use withState when accessing state in an unobserved context.

Try it out today

We just pushed a branch off of main, store-send-and-with-state, and opened a pull request here. Please give it a try in your applications, and let us know if you have any feedback!

[schrismartin]

Regarding Store.withState, I'm curious about the decision to create this extra helper rather than exposing a (read-only) state property on the store. This would enable the following syntax using existing tools:

let currentState = store.state
// Do something with the current state...

// Pluck the current count out of the store:
let count = store.scope(state: \.count).state
// or
let count = store.state.count

I'm probably trivializing something, but I don't quite understand the need to open the closure context here.

store.withState { currentState in
  // Do something with the current state...
}

[stephencelis]

@schrismartin Because SwiftUI views hold onto the store, providing direct access to state would make it far too easy for folks to accidentally access this state and not the state of an observed view store. And with this kind of mistake comes a painful debugging process to track down why a view isn't updating because it accesses store.state.count instead of viewStore.count. Because of this, we don't think it's a good idea to provide access to state directly right now.

I'm probably trivializing something, but I don't quite understand the need to open the closure context here.

store.withState { currentState in
  // Do something with the current state...
}

It's mainly to show what the API expands to, but there's plenty of work you may want to do in there. In UIKit you may want to open store.withState in viewDidLoad to access a bunch of fields all at once, etc.

[schrismartin]

Because SwiftUI views hold onto the store, providing direct access to state would make it far too easy for folks to accidentally access this state and not the state of an observed view store.

Understood. In other words, the added ceremony here serves the purpose of being incongruent to prevent people from accidentally misusing it in place of viewStore. I can get behind that.

I'm probably trivializing something, but I don't quite understand the need to open the closure context here.

store.withState { currentState in
  // Do something with the current state...
}

It's mainly to show what the API expands to, but there's plenty of work you may want to do in there. In UIKit you may want to open store.withState in viewDidLoad to access a bunch of fields all at once, etc.

Perhaps to clarify my question a bit, would it be equally valid to do something like this?

let currentState = store.withState { $0 }
// Do something with the current state...

Looking at the PR, it looks like yes. If so, that's only mildly less convenient than a direct store.state accessor. Do you think it would be worth it to have store.withState always return Void, forcing you to deal with currentState within the scope of the closure?

store.withState { currentState in
  self.label.text = "Current count: \(currentState.count)"
}

I know the above syntax is possible with its current manifestation. I'm just concerned that returning the contents of the closure doesn't quite do enough to steer folks toward using viewStore.

[stephencelis]

store.withState { $0 } is totally valid and fine to do, we just want the syntax to make it very clear that you're escaping the current state into a local scope and using it detached from the store.

If folks reach for store.withState(\.count) and don't get view updates, we think there's a clear enough indicator of syntax to learn from.

I could see at the most bike-shedding a clumsier name like store.withCurrentState or store.withUnobservedState, though I'm not sure it's necessary to take things to that level.

[fabstu]

Note that accessing state this way does not perform any observation at all.

Is this only in regards to let count = or also in regards to the closure?

[stephencelis]

Any state you access using store.withState will not be observed by SwiftUI. You must use WithViewStore or @ObservedObject var viewStore for a view to observe changes to state.

[acosmicflamingo]

I'm DIGGING this new functionality! Works out-of-the-box; very elegant to have a way of accessing within a closure and also pluck it out! When creating a UICollectionView instance using cell registration API, the plucking makes getting state trivial:

-      super.init(collectionView: collectionView) { [weak store] collectionView, indexPath, itemId in
+      super.init(collectionView: collectionView) {
+        [weak store] collectionView, indexPath, itemId in
         guard
           let store,
-          let item = ViewStore(store, observe: \.section.items[id: itemId]).state
+          let item = store.withState(\.section.items[id: itemId])
         else {
           return nil
         }

This also will make it's way in all the CollectionViewDataSource, CollectionViewDelegate classes I have throughout my codebase too.

[acosmicflamingo]

One question I have is whether the long-term vision is to phase out the concept of scoping and transforming business state to view state and that store really becomes the single source of truth and everything is just a mere reflection of that. Although I see how people find ViewStore to be really annoying, I've really enjoyed it because of the high-level scoping that it provides. Practically all view domains in my codebase do something like this:

public class FooController: UIViewController {
  public let store: StoreOf<Foo>
  public var viewStore: ViewStore<ViewState, Action.ViewAction>

  public struct ViewState: Equatable {
    var buttonColor: UIColor

    public init(state: Foo.State) {
      switch state.houseTemp {
      case .HOT:
        self.buttonColor = UIColor.red
      case .normal:
        self.buttonColor = UIColor.lightGray
      case .cold:
        self.buttonColor = UIColor.systemBlue
      }
    }  
  }

  public func setupBindings() {
    viewStore.publisher.buttonColor
      .removeDuplicates(by: ==)
      .assignNoRetain(\UIButton.backgroundColor, with: myButton)
      .store(in: &cancellables)
  }

To me, this kind of logic does not belong anywhere near a reducer because it is 100% view logic. When it comes to testing, then all I have to do is just create a FooViewController.ViewState, pass it some parameters, and make assertions. No need to do anything with stores there. I'm wondering how (or if) view logic will be kept in its own sandbox while the business logic remains elsewhere during these attempts of phasing out ViewStore.

[stephencelis]

(Replied below in another comment, but we hope that macros will eliminate the need for view stores even in pre-iOS 17 apps.)

[acosmicflamingo]

Second question is whether the path forward would mean I can no longer scope an action to a domain like ViewAction à la Krzysztof Zablocki's TCA boundaries. I really dig being able to just run viewStore.send(.someViewAction) and not have a bunch of other actions appear, since I've scoped my view store to be ViewStore<ViewState, Action.ViewAction>.

This is of course is NOT a big deal at all. If I lose this feature, then I'll just write myself a SwiftLint rule that catches instances when I'm not passing a .view(.someViewAction) to the Store instance. I'm only asking out of curiosity :)

[stephencelis]

Ideally the macro approach can be applied generally, including UIKit, once Swift 5.9 is out. @mbrandonw fleshes out the vision a bit more here: #2223 (reply in thread)

[acosmicflamingo]

Gotcha; thanks! Yes I can definitely see macros helping here. Huh, macros came at the right time for you guys 😄

[natemann]

I honestly do not see the need for this change quite yet. I understand ViewStore will go away completely, but I really do not see the need of this incremental step. ViewStore(store).send is annoying, but is definitely not the primary way to send actions in code bases. In my own code base, I call WithViewStore(store) over 150 times, but only call ViewStore(store) less than 5

[mbrandonw]

ViewStore(store).send is annoying, but is definitely not the primary way to send actions in code bases.

The important thing to realize is that in 1.0, the syntax is not ViewStore(store).send. That version of the ViewStore initializer is completely going away. Instead, it will be ViewStore(store, observe: { $0 }).send. Or even ViewStore(store, observe: { $0 }, removeDuplicates: { _, _ in true }).send if the state has not been made equatable yet.

That is the main thing we are grappling with for 1.0. We want to make it not entirely horrible to send actions when you don't have a view store. And considering what we know about the future of Store/ViewStore, this small step (muddy as it is) doesn't seem like a big deal to us anymore.

Another thing to contend with is that Store feels too SwiftUI centric right now. There are a lot of people that use TCA outside of SwiftUI, and it is very weird to create a ViewStore to get access to state and actions in those situations. As @stephencelis mentioned in the original post, Store really should have a state publisher too.

because the Observation stuff that was showcased on socials seemed to be pretty independent from what's being proposed here (especially the withState stuff).

Considering that we know how TCA is eventually going to evolve, and considering that sending actions without a view store is very annoying (however rare it may be), it's hard for us to justify keeping around this facade of a "view store" as a separation from the runtime Store and observable ViewStore.

We're also thinking that by the time Xcode 15 / Swift 5.9 is officially released, we may be able to deprecate the concept of a view store entirely thanks to macros. Even before you can support iOS 17. You should be able to apply a macro (e.g. @ObserveState, @WithViewStore, etc.) and it add an @ObservedObject to your view with a send method for sending actions. You wouldn't have to use WithViewStore, wouldn't have to incur another indentation nesting, and hopefully would relieve some stress on the compiler.

[ghost]

The important thing to realize is that in 1.0, the syntax is not ViewStore(store).send. That version of the ViewStore initializer is completely going away. Instead, it will be ViewStore(store, observe: { $0 }).send. Or even ViewStore(store, observe: { $0 }, removeDuplicates: { _, _ in true }).send if the state has not been made equatable yet.

Hi @mbrandonw. What about ViewStore(store.stateless).send ?

[mbrandonw]

That will not work either. The initializer on ViewStore that does not have an observe argument is being deleted from the repo. It is far too dangerous for people to create view stores that observe too much state, and we have found it very helpful to guide people to thinking about that by making the observe argument upfront and center.

[ghost]

Ah, bummer... I rather like ViewStore(store.stateless).send. It's ok, though, because In our project we're now establishing the convention that all our views will have an associated MyViewState struct and will use the paradigm below:

struct MyView: View {

   private let store: Store<State, Action>
   @ObservedObject private var vs: ViewStore<MyViewState, Action>

   init(store: Store<State, Action>) {
      self.store = store
      let vs = ViewStore(store, observe: MyViewState.init)
      self._vs = .init(wrappedValue: vs)
   }

}

So, we can always just use vs.send(...) and won't need to make use of ViewStore(store.stateless).send.

The convention we're now establishing is a little verbose but it makes it easy to update the view as needed. It also removes the extra indentation caused by WithViewStore, which I personally always found annoying.

[mbrandonw]

Well, if we decide to move forward with this RFC you will also be able to simply do store.send(…) instead of ViewStore(store.stateless).send for all the times you do not have a view store at hand.

[stephencelis]

Hi all! Thanks again for participating in the discussion. Given the general positive response, and the vision for the future of the library, we think this intermediate change is worth making before 1.0, so we're going to merge the associated branch now.

[acosmicflamingo]

Now that the store's publisher is exposed and ViewStore is on it's way out the door, does it make more sense now to expose a store's state as read-only properties? Or perhaps this could just be a UIKit-specific feature LOLOL

[stephencelis]

@acosmicflamingo That's generally the idea of withState, which should give a UIKit feature the ability to peek into state and do what it needs to do outside of a publisher subscription. We'll be exploring .state as a public property more soon with observation on the horizon, though!