> I meant that many people imagine Component class as being the meat of the codebase, heavily operating on `this` and updating things on it. Yeah maybe. Even w

> I meant that many people imagine Component class as being the meat of the codebase, heavily operating on `this` and updating things on it. Yeah maybe. Even when it's not true it is still a valid way of looking at it I think. In the abstract sense that's what's being modelled here with the API, right? The fact that the internals are different is an implementation detail. Of course, it might be an interesting detail, hence your blogpost. > Similarly folks often imagine `this.state` being the source of truth (and thus Hooks seem too ephemeral). I still don't understand why this is though. In some of my projects I actually manage my own local state on the component class (without this.state/setState) and auto `forceRender` when something changes. In those cases my state is super sync and everything works fine. With the additional benefit of my local domain logic being modular: I can read my state after having updated it and it works like expected. So know I can write multiple methods dealing with my local state and compose them freely — like actual OO. I understand the hooks world is a different story, but in the compat component world it all seemed just fine. Why doesn't react use `this.state` as the source of truth, or update it more aggressively so it at least looks like the source of truth to me? Perf reasons? Is it worth it?