Multi-store architecture with 4 tabs app

[mariob]

Hi everyone,

I'm currently building an iOS application with 4 tabs and I'm considering using a multi-store architecture to manage the state of the app (pretty much a store per tab). My concern is that using a single store for the entire app could result in a lot of unnecessary "state updates" for actions that don't affect the other tabs. By isolating each tab to its own store, I hope to reduce the amount of traffic and improve the app's performance.

For example, I'm using the 'computed property' pattern for child-states, which creates a new instance each time an action enters the store and each Scope(...) is evaluated. I'm not doing anything in the child feature's inits and only property assignments in child feature's state init but still a lot of unnecessary computation is happening. It sounds that this should be negligible for 4-5 scoped child features, but maybe I'm wrong?

However, using multiple stores means I'll need to use stateful clients to share data between them, which is not a problem but I like the idea of having the user's data in the root state and just have stateless clients if possible. Currently, I have a significant portion of my app's data stored in the root reducer's state, which is shared among three of the child reducers (i.e. the tabs). If I switch to a multi-store architecture, I'll lose that ability.

A thing that I appreciate with having stateless clients is that the session's data is automatically cleaned at logout because the 'AppFeature.State' is replaced with 'SignInFeature.State' (enum routing).

Another downside with putting the shared state in dependencies are that I need to start to subscribe for data-change notifications via AsynStream or something similar to update the state, which requires running a long-living effect in each tab.

I'm wondering if anyone else has experience using TCA with a multi-store architecture in a similar setting? If so, how did it work for you? Did you encounter any issues or limitations? Did you reverted back to a single store?

Any feedback or advice would be greatly appreciated!

Thanks,
Mario

[tgrapperon]

Hey @mariob. I don't think that it'll worth it in the case of a tabbed application. In such apps, there is only one tab visible, hence only one active branch at a given moment. The other stores for the inactive tabs are non-existing (even if their idle state can be stored in the root state).

It can make sense to uncouple a few stores in complex apps that are presenting many features at the same time (e.g. Mac apps), but I think the gain will be not be significative for a tabbed app, provided your ViewStores are only observing what they need to observe.

Without weighting yet on the pros and cons of what you're suggesting, do you have effective bottlenecks in your current situation?

[mariob]

Hey @tgrapperon

Thanks for the answer.

I was watching a video and read about TCA performance in general at Krzysztof's blog and was wondering if it could be a concern. But I guess your are right. It will only be a couple of struct instantiation for each action but nothing will be rendered unnecessary if I only make sure to observe what's necessary.

Currently, I don't see any bottlenecks. Some of my better/worse traits are that I tend to think a little too much about what may be needed in the future so I just wanted to check with the community what they think about this.

I'll probably try out the "computed property" way of sharing state, I like it and as you say, it won't be a big impact as long as I make sure to only observe the required data for each tab's view.

A fun fact - The app's memory usage almost decreased with 100Mb rewriting from UIKit+MVC+MVVM to SwiftUI+TCA). I'm not done yet but most things are in place so it's kind of impressing. Maybe I'll find some cache lurking around which I've missed 😀

[tgrapperon]

Some of my better/worse traits are that I tend to think a little too much about what may be needed in the future

You're not alone! I was very worried about the same kind of things at the beginning. But once you get how things are working, you can get a better sense of what really impacts performance.

Of course, the story would have been different in your case if all tabs where displayed at the same time, so as always, "it depends".

Krzysztof's experience is very peculiar, because he works on a large Mac app (the Arc browser), and they have tons of features that are running at the same time. The number of events he's advancing is one or two orders of magnitude the ones I'm experiencing in my rather busy app. I think that the best advice is to not optimize prematurely, as it's very easy to make your life more difficult for no real reason. TCA's modularity makes refactors relatively easy if you ever need to realize them.

[fabstu]

You can

a) Hold each store inside @State.

b) Initialize all four stores at the root of the app like the root store

c) Hold the four stores each in a static variable.

d) Hold the stores inside a dependency that maintains, syncs and returns them.

I did a) for composability+for automatic deinit and a small bit d), but I would probably choose b) or c) for simplicity if I could and d) if it is many stores of the same type.. or maybe c) and d) are equivalent. Don't choose a) If you wanna reorder tabs on-the-fly while depending on .tasks for initializing and updating the stores.

[mariob]

@fabstu For any of the options, I guess that all the shared state needs to be synchronized using some kind of stateful dependency, right?

I wonder if this will actually be more efficient that only having one store... all the synchronization between the stores also comes with a cost.

[fabstu]

Depends on what you optimize for and how you synchronize. If you have problems with actions or state changes slowing down the main thread due to action propagation or due to scoping propagation+equality checks then syncing fewer times reduces that hot path. And if you synchronize implicitly using an SQLITE database.. you can use that in such a way to only get updates when data really changes (which can be done on a background thread).

I only used SQLITE so far, others are probably more experienced with synchronization. :)

[mariob]

And if you synchronize implicitly using an SQLITE database.. you can use that in such a way to only get updates when data really changes.

Interesting, never considered using a db for that but would totally be an options for the app since we do have offline support. Then we could use the db for all data access and subscribe when changes happens.

Actually, we can probably do this even if we go for only one store instance. Then we don't need to hold the data in memory. I'll take a look at it, thanks.