rescope, ScopedReducer & AnyScopedReducer

[technicated]

I was wandering in the library's source code, when I stumbled across this types / functions. These were never talked about in the episodes, and I think the reason is that they are implementation details. I remember a time when Store.scope was a simple method with a relatively small body to sync parent / child state, but what about now?

So my question is, what are these (re)scope types and methods, and why were they introduced?
Thank you!

[mbrandonw]

Hi @technicated, this was introduced in the following PR #1316. It is an optimization that can be performed when constructing many deeply nested scoped stores. We can flatten the call stack by keeping track of the store at the root of the scoping process, and access its state directly.

We are hopeful that tricks like this won't be necessary soon. With #2527 and our upcoming observation tools, scoped stores will be drastically minimized and will not nest as deeply. And then in TCA 2.0, when we can force that scopes only ever happen along key paths, we may be able to essentially eliminate nesting entirely, in some sense.

[technicated]

Thank you for your response and fore the links, which I was not able to track myself! I had a feeling it was something along this lines but could not fully grasp it.

While we're at it, in what sense (if you can / want to foreshadow it 😇) will TCA 2.0 "mostly eliminate nesting"? If my parent state holds a child state, and the child feature wants its Store<Child.State, Child.Action>, how can I avoid scope-ing the Store?

[mbrandonw]

If my parent state holds a child state, and the child feature wants its Store<Child.State, Child.Action>, how can I avoid scope-ing the Store?

I wasn't being very precise when I said "reduce nesting", but what I was technically referring to was the stack trace. Currently we incur a few stack frames each time you scope a store, and we believe we can massively flatten that.