[sleepinseattle]

The article is just demonstrating storing application state directly in views. Which you can do in any UI framework and works fine for small apps, but quickly falls over if the state affects multiple views. That’s the whole point of the various Model-View-* patterns, and doesn’t become less relevant just because the UI framework offers reactivity or data-binding.

[ajconway]

If the state affects multiple views, the views should be a function of that state.

The point of reactive UI is to not deal with events that affect data that affect presentation. Instead, you construct "presentation" every time the data changes, and the framework makes sure to reflect that in an optimal way.

[sleepinseattle]

What is this if not an event?

Button(action: { self.isPlaying.toggle() }

They just happen to be handling it entirely within their view component instead of making it a function on some controller/ViewModel/whatever object that then goes and updates the bool. Each framework then has its own code gen or library or runtime magic that makes that bool change get reflected in other views.

[mpweiher]

Aka: a View in MVC.

(Not to be confused with what Apple, for example, calls MVC, which is more like MVP).