[madhadron]

I mean, of course you lift the state. It's just like a database. You have a normalized model containing the state, and the GUI is a view on it. Events from the GUI trigger transactions that update the state and then every element is triggered to update itself based on the new state. That should never trigger a loop of events, because a view updating itself from the model should never trigger transactions on the database.

Many complicated views have their own internal models for things like where they are scrolled, what columns are shown, or what elements of a tree are expanded. But those compound views are written so that, from the outside, they appear exactly the same as any other view.

> I’d love to hear what the functional programming camp has to say about this problem

It's called functional reactive programming.

[nikisweeting]

This is the key line that the original article is missing imo, which solves much of the headache that they claim exists with message passing/raising state:

> a view updating itself from the model should never trigger transactions on the database

i.e. a view rendering from state/messages, should never re-emit new state/messages.

[Chris_Newton]

I thought the article was too dismissive of concepts like MVC, immediate mode and functional programming, given that ideas coming from those directions might offer the answers the original author is searching for.

The separation of an underlying data model from any particular way of presenting its current state is a powerful idea that has proven its value many times. We’ve used it to build user interfaces, from early GUIs when we didn’t yet have the kinds of libraries and platform APIs we enjoy today, through games with unique rendering requirements and a need to keep frame rates up, to modern web and mobile app architectures. The same principle is useful for building non-user interfaces, too, in areas like embedded systems where you are “presenting” by controlling some hardware component or distributed systems where you are “presenting” to some other software component as part of the larger system.

[erdo]

Agree completely other than the functional bit (but I'm not sure if that was a recommendation or just Google keyword help). At least for Android, I've found that maintaining state when handling screen rotations etc becomes a real headache if the GUI binding code is functional (there is nowhere nice and clear to hang the state without storing it in an rxStream or similar). So far I favour reactive code absolutely, and functional (ish - I'm still using DI for example) code right up to the view layer, but then drop out for the last mile of data binding