Sending actions without needing to access state

[jefflewis]

In some places, I have code that reacts to something outside the scope of a view store. In these cases, I need to send an action to the store, so I'll in-line a new ViewStore and have it send the action.

Is there a "better" way to send an action to the store in these contexts?

[mbrandonw]

What you are doing is the recommended way. We even have soft deprecated the idea of observing “stateless” stores just to get access to sending actions:

swift-composable-architecture/Sources/ComposableArchitecture/SwiftUI/WithViewStore.swift

Line 695 in bcae29f

message: "Use 'ViewStore(store).send(action)' instead of observing stateless stores."

[GreatApe]

But would we even need "unchecked" stores for this? Can't stores just simply accept actions? I understand the need for ViewStores for observation, to avoid re-rendering, but is there really a compelling reason to not expose send on stores directly?

[mbrandonw]

but is there really a compelling reason to not expose send on stores directly?

In my opinion yes, and it has been detailed many times in discussions, including the one I linked to above. Here and here are direct links to my previous comments.

If anyone wants to experiment with the API design to show how they want things to look while still meeting the needs of the library, then we will happily look at it and discuss things. But I must warn that things are more nuanced than seems at first, and you will need to show actual, compiling code for us to take the suggestion seriously.

[GreatApe]

Sorry, I didn't mean that we should eliminate ViewStore's ability to send actions, the normal usage should still be WithViewStore with scoping of state and potentially send if you want to.

But since there are so many situations where people want to send actions but don't need a stateful ViewStore to observe - if for no other reason than that we want to minimise the scope of the ViewStore in terms of lines - then it seems we only have a few options:

1. Create a second WithViewStore, wrapping only the Button for example
2. Use ViewStore(store).send
3. Allow store.send
4. Let the existing, main WithViewStore encompass everything

It would seem that your argument does not explain why (2) would be preferable to (3), and both (1) and (4) seem less than optimal

[mbrandonw]

It seems strange, to me at least, to have two different ways of sending actions. The most common use case is that one has a viewStore readily available for sending actions, but there is this small edge case of sometimes wanting to send actions without a view store. Making send public on Store just to serve this small need feels like a bandaid, and I'm still hoping there is a better solution once we can devote more time to exploring some of the new tools coming to Swift.

[GreatApe]

I wouldn't say it's a small edge case, or even an edge case at all -- we probably have it in every third or fourth View. But sure, it's a bit strange to have both options perhaps.

One random idea that you probably already thought of:

StoreState(store, observe: \.viewState, send: Action.view) { state, store in
    // state is just the current version of viewState
    // store is scoped according to send
}

[GreatApe]

I take this to mean that ViewStores are both very lightweight so we don't need to worry about creating them, and also that creating lots of copies of the "same" ViewStore won't e.g. confuse SwiftUI?

But I do wonder, what is wrong with the stateless version? Wouldn't that just be exactly the same thing, but with even less overhead?

[tgrapperon]

creating lots of copies of the "same" ViewStore won't e.g. confuse SwiftUI

In this case, SwiftUI doesn't see any ViewStore at all. Almost all the occurrences of stateless sends are used by simple buttons that will thus emit at a very low frequency. You wouldn't use this in a Slider for example, as you would also need to observe the value to form a Binding.

In the general picture, SwiftUI seems pretty efficient at dealing with different ViewStores instances, even if it would be ultimately preferable to limit their count using @StateObject instead of @ObservedObject.

Wouldn't that just be exactly the same thing, but with even less overhead?

You're creating an @ObservableObject which is not free on SwiftUI's side, and useless in terms of observation. You're even creating it if no one pushes the button, so ultimately, you're potentially creating more overhead than less.

This is not the end of the world, and likely not what will bring your application on its knees, but small un-optimizations do accumulate, and it's usually better to implement things in the most efficient way possible. Not observing stateless ViewStores is one way to do it.

[GreatApe]

Aha, so the point is that we should make inline ViewStores when we don't need state, rather than WithViewStore or ViewStores as properties. Doing ViewStore(store.stateless).send or storing a stateless store is not an issue for example.

[tgrapperon]

Exactly. WithViewStore means that you're observing its ViewState. If the ViewState is Void, there is nothing to observe, so you can forgo WithViewStore. As what usually remains are state-independents Buttons, you can create an instance on action.
That being said, there is nothing wrong to reuse a ViewStore instance if you happen to have one at hand (or nearby).
One frequent pattern you will encounter is a stateless button next to a stateful scoped view, and one may be tempted to write

WithViewStore(store.stateless) { viewStore in
  CollectionView(
    store: store.scope(
      state: \.collectionView, action: Action.collectionView
    )
  )
  Button {
    viewStore.send(.reset)
  } label: {
    Text("Reset")
  }
}

But in this case, you can probably rewrite as:

CollectionView(
  store: store.scope(
    state: \.collectionView, action: Action.collectionView
  )
)
Button {
  ViewStore(store.stateless).send(.reset)
} label: {
  Text("Reset")
}

According to my experience, folks often assume that you need to observe the stores you scope, which is not the case. In this example, you would be able to completely avoid defining a useless WithViewStore. Furthermore, given where this configuration occurs, you can sometimes save 0.1s of build time, and you'll usually get better error/warning reports from your View, and more responsive SwiftUI previews (or even allow them to build at all).