Beta: Child store caching

[mbrandonw]

Hello all, we have another beta we’d like to get in the hands of library users before official release. This beta doesn’t bring a ton of new features to the library like our previous ones did, but it is a very important foundational change to the library that will be crucial for our work on introducing @Observable to the Composable Architecture. So we want as many people to try it as possible to make sure everything is kosher before the final release.

The changes are what is contained in this PR #2527. It adds a new scope operation on stores that takes a key path for the state transformation and a case key path for the action transformation:

// before:
store.scope(state: { $0.child }, action: { .child($0) })

// after:
store.scope(state: \.child, action: \.child)

You will need to have updated your feature’s reducer to use the new @Reducer macro in order to take advantage of this new syntax. See the release notes of 1.4 for more information.

It’s a very small change, but thanks to the hashability of key paths we can start caching the stores created by scope so that if you ask for a store with the same key paths later, we can serve up the cached one rather than create a new one.

This is not only good for performance, but it also starts to give a stable identity to stores and the collection of stores forms a persistent tree-structure that mimics the tree structure of the composed reducers. This will unlock a ton of things in the future, but for this release it unlocks one small, but welcomed, nicety.

Previously to drive navigation off of an optional enum you needed to use the view modifiers that come with the library, such as sheet(store:state:action:):

.sheet(
  store: store.scope(state: \.$destination, action: { .destination($0) },
  state: \.sheet,
  action: { .sheet($0) }
)

This requires you to provide a store scoped down to the enum domain, and then two additional transformations for isolating the enum cases of the state and action enums that you want to drive the navigation. This was the best API we could come up for this, but it’s cumbersome.

Well, in this branch it can now be shortened to just one line:

.sheet(store: store.scope(state: \.$destination.sheet, action: \.destination.sheet)

So, we would love if everyone could point their projects to the store-tree branch of the Composable Architecture and let us know a few things:

1. Does your project still compile? We always aim for releases to be backwards compatible, and so this one is no exception.
2. Does your test suite still pass and does your app still work the same as it did before?
3. Can you update some of your store.scopes and let us know if it works for you? Does your app still behave the same with the new caching behavior? Remember that it requires you to be adopting the new @Reducer macro introduced in 1.4.0.
4. Are there any store.scope instances in your code base that cannot be cleanly migrated to the new version of scope?
5. For features that are using navigation view modifiers like .sheet(store:state:action:), can you try using the simpler .sheet(store:) version using dot-chained state and action paths, and let us know if everything still works as you expect?

Thanks again for helping, and we hope these new features improve your apps and your developer experience. And soon we will be sharing the public beta of the Composable Architecture integrated with Swift 5.9’s new Observation tools. 🙂

[acosmicflamingo]

Anyone that scopes state into a store of a different dimension (e.g. creating a tuple out of state) would greatly benefit from using subscripting. This is what Stephen recommended: #2527 (comment)

[mycroftcanner]

1. yes
2. yes
3. yes
4. no
5. yes

[taskcruncher]

In the one feature that I've updated to use @Reducer, everything worked with the new method signature, and the app overall compiled. A very nice syntactical change.