In modern frontend architecture, the word “state” has gradually become overgeneralized.
API payloads, user input, computed frontend values, request loading status, and even the result of a side effect are often all placed under the broad category of “state.” At the UI level, this seems reasonable—anything that triggers a UI update looks like state. And once something is considered state, we tend to put it into a component, a store, a ref, a reactive object, or whatever state management tool is at our disposal.
But this is exactly where the problem begins. When the semantics of State, Derived State, and Effects are blurred together, the boundaries of the system’s data flow gradually start to collapse.
State is Not a Catch-All Term
From an architectural perspective, I prefer to think of State as the source of truth within a data flow.
