Thursday, July 7, 2022

UIs Are Not Pure Functions of the Models

Jesper:

View models and functional UI look like solutions, and they are indeed effective ways of managing complexity by making all the constituent state visible and enumerated. But in my experience they also encourage a way of programming where you bind as much as possible, and the problem with that is that, as the title of the post notes, UIs are not pure functions of the models.

If you go from one place in your UI to another, you may want to be stopped because there are things that don’t validate or don’t fly. You may have pending changes that should neither automagically apply nor be lost. Both SwiftUI and React have state as a first-class concept and are theoretically well-equipped to handle this; what’s worse is that we don’t have a handle on it.

We don’t know how to think in state. For the edited-but-not-saved text of a text field, sure. For the in-progress-but-not-committed-changes in what is at least partially modal, somewhere in the UI? Hm, well, that sounds like a tree of Redux reducers - and therefore model data - or a bunch of nested view models to me. The SwiftUI talk mentions “sources of truth” a lot. Here, the source of truth for the hitherto unsaved data is nebulous. Living in 107 state variables? Living in provisionally updated properties of an ObservableObject that is kept uncommited from the database or real source of truth?

Previously:

1 Comment RSS · Twitter

Let's hope it's not a 'jumped the shark' moment. It seems a shame to have 'deprececated' UIKit just as it was reaching maturity.

Leave a Comment