Or not. You mention the biggest problem with the entire unidirectional data flow issue and that's performance in larger applications.

Yes, we can get around that by attempting to break up the data flow into data flows, but that still leaves us with greater complexity in implementation. The example shown is nice, but plays to the strengths of the system and minimizes the complexity of attempting to route each and every state change through the system.

SwiftUI is biased towards distributed state, observable objects, published values, and more to the point here, bindings. TextFields, Toggles, and may other view types depend on published value and state bindings which can be extremely difficult to integrate into a unidirectional flow.

I wrote an article, SwiftUI: Choosing an Application Architecture, and in it I made one observation.

“Too many people attempt to shoehorn their favorite architectures and design patterns written for other platforms and other languages onto Swift and SwiftUI.”

That includes uni-directional data flows and systems like Redux.

That article also contained my own personal criteria for choosing a SwiftUI architecture…

* It must be performant, no matter the application size.

* It must be compatible with SwiftUI behavior and state management.

* It should be concise, lightweight, adaptable, and flexible.

* It encourages SwiftUI view composition.

* It supports testing.

In other words, it lets SwiftUI be SwiftUI.

All that said, nice work on the article. Well-considered, well-written, and a pleasure to read.

Here's a link to the article if you're interested.

https://betterprogramming.pub/swiftui-choosing-an-application-architecture-6ec9289f8e8f