My bias toward boring state management

I have a strong bias toward boring state management. Not simple in the naive sense, and not under-engineered. Boring means the system has fewer surprising places where truth can hide.

Large Angular apps become difficult when no one can answer basic questions quickly: who owns this state, who derives it, who can mutate it, what happens when the request fails, and what state does the user see while the app is between decisions?

I like small view models, typed transitions, explicit loading and error states, and feature boundaries that can be tested without rendering the entire product. RxJS is powerful, but I do not want streams that read like a dare. Signals are useful, but they do not remove the need for ownership.

The best state approach depends on the feature. Some state belongs near a component. Some belongs near a route. Some belongs behind a service. Some deserves a store. What matters is not the tool; it is whether the team can reason about the lifecycle without relying on memory and superstition.

I also care about how state reads in the template. If the view is doing too much interpretation, the user experience is probably scattered across the wrong layers. Derived state should have names. Product states should be explicit. Edge cases should be visible enough that a reviewer can find them.

Boring state management is not a lack of ambition. It is respect for the people who will debug the product at 5 PM when a customer path breaks in a way nobody demoed.

The goal is not to remove complexity. The goal is to keep complexity in places where the team can safely work with it.