In previous articles, I discussed Testability and API Boundries when using The Composable Architecture. This week I will dive into performance and a design pattern you might consider: multi-store. This pattern can improve performance and enforce rigid API boundaries.
How are actions processed in TCA?
TCA implements a Unidirectional Data Flow (UDF). Using a UDF ensures that events and data in your application moves in a consistent and predictable manner. Following this pattern can reduce data inconsistencies because the source of truth for your application is the same throughout the whole application.
UDF in TCA
In TCA, the State managed by the root Store is the source of truth for your application. As different parts of the application need less and less of the overall application state, you use scope functions for whittling the State down into smaller components. One interesting aspect of the State is that it is not required to be Equatable , and there is no dependency graph through the application that is maintained automatically by TCA.
Why is this important?
Whenever we process actions in TCA, the architecture has to assume that the Root State has changed, and call all of our scope functions again and again.
Those scoping functions will be called tens of thousands of times during user sessions, and as such, you need to be careful what code you put in them. You should avoid any calculations in that function and have as simple operations as possible.
Even sending a no-op action into TCA system will use significant cpu / main thread processing time because of all the scoping calls.
This post is for paying subscribers only
Sign up now to read this article and get access to all premium posts.
Already have an account? Sign In
