Does TCA really meant to be a single state/store per application?

[shahzadmajeed]

Hi,

We are in the middle of some R&D on TCA and the perception is that TCA encourages to use single store/state in the application instead of local states/stores per feature? If that is true then:

1. What are the benefits of using single store/state in application?
2. How would you share 50 screens/features state in a single state/store and still be able to build & test those 50 screens/features in isolation? Is this approach really recommended for large scale application?
3. How do we manage/inject dependencies in TCA? Which entity handles that? Is that Environment?
4. Are there examples of how different frameworks/modules are going to pull state from a global/state store when they need some shared state?

Thank you for your input

-Shahzad

[mbrandonw]

TCA applications are indeed meant to be run off a single store, but we don't force that in anyway, so you are free to come up with your own patterns if you feel the need.

It's worth noting that although it is true that a single store powers the entire application, it is not true that every single view in the entire application holds onto that store. In reality you use tools like pullback to break down reducers into smaller ones, and tools like scope to break stores into smaller ones. That allows you to build features in isolation that only operate on the specific domain they care about, and then all those features plug together to form the main store.

Further, by using ViewStores precisely you can make sure that views observe only the bare minimum of state they are about. So, just because your state models a deep navigation stack, such as A→B→C→D, the changes to D's state do not need to make A, B, and C re-render their content.

[shahzadmajeed]

So, what I'm trying to understand is the benefits of a single store in following scenario:

Let's say we have a large scale application with 50+ screens/features built as separate modules/frameworks. Each screen fetches it's own data from backend on load and never shares this local data with any other screen. The data could be from bytes to several MBs and need to be purged when that screen is dismissed.

Some screens might care about some of the shared information in global state like user account, cookies, or some other app information.

1. Wouldn't it increase the memory footprint to hold state of 50 features in global state needlessly? Also, it will complicate global stores unnecessarily?
2. Shouldn't global state only hold cookies, user information and other pieces that are actually shared across the app?
3. We can still pullback a reducer for this minimal shared/global state in features? This way we don't have implement our own pattern to manage communication between features and global state/store?
4. Why would you still prefer global state in this case and what are the benefits?

What do you think?

[mbrandonw]

Your app may have 50 features, but are all 50 features active at once? If they are, then you are going to have memory problems regardless if you have 1 store with 50 features or 50 stores with 1 feature.

In practice, an app with 50 features does not have all 50 active at once. Say you have a tab bar application with 4 tabs, and each tab is a feature. That means when the application first starts you have 4 active features.

Then say the first tab has a drill down to another feature. That feature is not active until you actually drill down. You can model that with optional state so that it is nil until activated and its view is not shown until it is activated.

Then say that drill down screen has a feature that can appear in a presentation modal. That feature too can be modeled with optional state so that it is nil until it is activated.

If you keep going down this route you will see that your application state is a tree of nested optionals and enums. Rather than thinking of app state like this:

struct AppState {
  var feature1: Feature1
  var feature2: Feature2
  var feature3: Feature3
  var feature4: Feature4
  var feature5: Feature5
  ...
  var feature50: Feature50
}

What you really have is more like this:

struct AppState {
  var tab1: Tab1
  var tab2: Tab2
  var tab3: Tab3
  var tab4: Tab4
}

struct Tab1 {
  var drillDown: DrillDown?
  ...
}

struct DrillDown {
  var modal: Modal?
  ...
}

struct Modal {
  ...
}

struct Tab2 {...}
struct Tab3 {...}
struct Tab4 {...}

In order to achieve this you need to make use of all the domain modeling tools that come in TCA. They allow you to use optionals and enums to create a tree of state, and then you use the reducer and store operators to compose those things.

Some screens might care about some of the shared information in global state like user account, cookies, or some other app information.

State that needs to be globally accessible should be modeled in the environment, not in state. You think think of it more like database access or user defaults access. There is a new discussion about this topic (here) and I've previously discussed it on the swift forums (here).

[shahzadmajeed]

You definitely don't have all the 50 features active at the same time but as you keep visiting those screens you keep initializing global state with those local states hence your memory foot print keep growing unless you implement an explicit state purge action for every feature so that you clear that part of the state when a screen disappears?

and thank you for confirming modeling of shared state in environment.. that is exactly that I expected

[mbrandonw]

unless you implement an explicit state purge action for every feature so that you clear that part of the state when a screen disappears?

That is exactly how the system works. The only way to get a modal to appear is to flip an optional piece of state from nil to non-nil, and the only way to dismiss the modal is to flip the optional back to nil. This means you can't even make a screen disappear unless you nil out the state.

You usually do not even have to think about clean up that state explicitly. It's all handled by SwiftUI bindings and the tools that TCA ships with. The act of dismissing (say hitting the back button or swiping down) causes SwiftUI to write nil to a binding, which sends an action into the store, which then nils out the state.

And we are working on some navigation tools that will make all of this even nicer. It's like what we open-sourced for swiftui-navigation, but tailored for TCA.

[shahzadmajeed]

I see.. does TCA system work same way for UIKit as well?

[mbrandonw]

Yes it does. We have some case studies showing the basics, but it's not as fleshed out as our SwiftUI demos are. But, at the end of the day you still want presentations and dismissals of controllers to be driven off of optional state.

[shahzadmajeed]

Got it. Thank you for sharing your input 👍