You don't really have to do anything special with React's lifecycle in order to publish changes... you just call forceUpdate on a component to trigger itself an

You don't really have to do anything special with React's lifecycle in order to publish changes... you just call forceUpdate on a component to trigger itself and its children to re-render. The trick is avoiding rendering the parts of that tree which won't actually change. Redux solves this through immutability which allows for reference comparison ("if this component's props didn't change then the object will === the previous one, and we can skip it"). MobX does it by automatically wiring highly granular pub/sub relations between individual variables and the components that reference them. Additionally, events aren't sufficient on their own because you need the state to actually be stored somewhere, for next time. Events don't hold state, they only pass a transient signal. And if you're manually both a) publishing an event and b) updating the corresponding state, you risk missing a case and having those two get out of sync (not to mention you'll be writing a whole lot of boilerplate logic). It'll also be really hard to change multiple pieces of state at once without having things temporarily disagree. I've worked on a project where this is basically what was done, and it was a nightmare of inconsistent intermediary states and race-conditions. To put it differently: "state X changed" is a special case of "X happened" that needs quite a few special considerations in practice, and that's why state management abstractions are built atop the more general idea