New slide for my presentation, trying to describe the “coupling” between ViewModel and UI, in both Imperative and Declarative UIs

Hi I'm confused by this slide and it might be because I lack the context of the presentation. However are you implying the ViewModel is tightly coupled to an imperative UI because it store and sets views?

I am using a broad definition of “ViewModel” here, not necessarily referring to the Android’s ViewModel component, but to any code layer in an Android/iOS application which is connecting the data to the UI components. In the case of Imperative UI toolkit there is an implicit coupling, as there is the need to link any data to the specific UI component. For doing that, the “ViewModel” needs to be aware of the component ID. In a Declarative UI toolkit, using the MVI pattern, the ViewModel doesn’t need to be aware of any UI component. What it does is just to pass the data (the app state) to the UI layer, and the UI components can freely use what they need.

The snippet on the bottom has no connection to the snippets at the top. Are you comparing how the text gets on the screen, or how changes to the model text get propagated through the data layer?

@Daniele B Oh I see thanks

I've been in this field long enough to see things come and go

Thats nice, but why would you assume the slide is saying the new takes on Declarative UIs are the "endgame of UI development"?

@Kirill Grouchnikov I am trying to show how ViewModel and DeclarativeUIs can be fully decoupled. As a consequence, the ViewModel can be fully shared using KMP.

What does that have to do with imperative UIs then? Focus on one thing on a slide

these are actually 2 slides, I just merged them together for convenience

We have "ViewModel" which does not need to know about view ids or anything. The second code example is pretty close to what our ViewModel looks with the imperative UI toolkit. It is not specific to declarative toolkits.

@curioustechizen I think you are thinking the same thing I did @Daniele B’s is using the

ViewModel

term to mean

I am using a broad definition of "ViewModel" here, not necessarily referring to the Android's ViewModel component, but to any code layer in an Android/iOS application which is connecting the data to the UI components.

I would say our ViewModel does fit that definition. The only imperative part of our UI is the view itself (sub-class of Layout in Android and UIView in iOS)

@curioustechizen For iOS do you write the views in Kotlin itself?

@curioustechizen I am actually showing a unidirectional data flow only for the Declarative UIs, while I could have also showed it for the Imperative UI example. This might be misleading. I didn’t mean to focus on the architecture, but on the degree of decoupling you can achieve with Declarative UIs, as the “View Model” doesn’t need to know the IDs of the UI components. I will consider if it makes sense to show it differently on the slides. One thing that you might also find misleading is in the definition of “ViewModel”. In my case “findViewByID” is part of the ViewModel, while I guess you consider it as part of the UI layer. I have been giving the definition of “ViewModel” as in the Leland Richardson’s article, where he also considers “findViewByID” as part of the ViewModel.

@birdsofparadise no. For iOS the views are written in Swift

@curioustechizen Ah for sure. Do you use SnapKit?

I have updated the slides, without referencing the ViewModel, as it can be confusing for someone:

The term

Controller

might work

Controller is a term mainly used for MVC, while the pattern I will be suggesting is MVI. I had complaints about the other slides, as I was showing an unidirectional data flow only for the DeclarativeUI, and not on the ImperativeUI slide. So I was in fact adding some architectural aspects, which were confusing people.

@Daniele B I think the term ViewModel and what you mean by it are indeed confusing because of the architecture components people are used to, I think on your last post where I commented perhaps that was the main cause of confusion as I see now. I usually call it the view layer (the layer that actually interacts with rendering). So activities/fragments/views are for me in the view layer, as they directly turn data into visible things and those components are platform specific. A view model in my eyes is simply the model which describes a view, but not necessarily renders it.

I think attempt to somehow show problem of View system by suggesting that somehow findViewById is somehow a problem is pretty pointless. It's not a problem and it doesn't create any coupling as this slide says

@gildor simply put, it creates less cohesion in the UI layer, by splitting the code in 2 separate files: code layer and XML Layout. While in the declarative UIs all happen in just 1 file.

Is there a message in this slides? From this thread and the one before it, my impression is that you're positioning declarative UIs to be clearly better than imperative one, and then arranging the supporting arguments around that. And as far as arguments go, the number of files is a weak argument.

@gildor it does have a dependency. Your Java code needs to know what is inside the XML, and then also it should hope that it exists, which I do consider a problem what has only been solved lately with view binding (and for years it wasn't solved, and still you have to manage the view bindings). With Compose you don't have this issue, as your code directly draws on the screen, instead of interfacing with another layer that might or might not exist.

I hope these new slides make the point more clear

I still think that "imperative ui toolkit" is pointless slide, it doesn't show anything "imperative" and such code easily can be a part of any kind code And it doesn't show any issues/advantages of any approach I think it's focus attention on unrelated and minor implementation detail

@gildor in imperative UIs, you necessarily have a middle layer, even if you use viewbinding. In DeclarativeUIs you don't have such middle layer, as you can apply the data values directly on the UI Layout components.

To be fair, react still has to interface with the underlying HTML and that is annoying as hell, even if react is pretty declarative. Compose has less of an issue as it just draws directly on canvas whatever you put in

On Compose and SwiftUI, you can apply the app state's values directly on the UI Layout components. Hopefully we'll have soon Compose for Web too.