The Composable Architecture

Set of best practices for The Composable Architecture projects based on experiences of the team at The Browser Company.

Let's talk about using multi-store pattern in TCA as a way to improve the performance and maintainability.

Last week I spoke at NSSpainX to talk about how to use Composable Architecture in larger projects, the kind of issues you might run into and how you can work around them. Mentioned articles are: - Exhaustive testing in TCA - TCA Action Boundaries - TCA Action Boundries - Convenience

Now that we added some structure to our TCA actions, let's add automation and convenience API's.

To maintain our codebases for years, we must create boundaries across modules. Here's my approach to doing that with The Composable Architecture.

Exhaustivity in the context of TCA tests means every test you perform has to replicate all the actions, state changes, and effects steaming from the first trigger you want to verify. It leads to a code that has a lot of TDD anti-patterns. Let’s get into the details.