https://kotlinlang.org logo
#compose
Title
# compose
d

Daniele B

12/07/2020, 6:22 PM
New slide for my presentation, trying to describe the “coupling” between ViewModel and UI, in both Imperative and Declarative UIs
b

birdsofparadise

12/07/2020, 6:33 PM
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?
d

Daniele B

12/07/2020, 6:41 PM
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.
k

Kirill Grouchnikov

12/07/2020, 6:43 PM
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?
☝️ 1
If the idea is to show how the declarative toolkits are "the best", I'm just going to say that this too shall pass, and in the next 5-10 years there will be something "clearly" better. We are not in the endgame of UI development in 2020/21 with Compose / Swift / React.
b

birdsofparadise

12/07/2020, 6:44 PM
@Daniele B Oh I see thanks
Copy code
If the idea is to show how the declarative toolkits are "the best", I'm just going to say that this too shall pass, and in the next 5-10 years there will be something "clearly" better."
Why would you assume this?
k

Kirill Grouchnikov

12/07/2020, 6:50 PM
I've been in this field long enough to see things come and go
b

birdsofparadise

12/07/2020, 6:52 PM
Thats nice, but why would you assume the slide is saying the new takes on Declarative UIs are the "endgame of UI development"?
👍 1
d

Daniele B

12/07/2020, 7:00 PM
@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.
k

Kirill Grouchnikov

12/07/2020, 7:01 PM
What does that have to do with imperative UIs then? Focus on one thing on a slide
d

Daniele B

12/07/2020, 7:04 PM
these are actually 2 slides, I just merged them together for convenience
But the point I want to make is that with Imperative UIs, you need to add an extra platform-specific layer, which couples the ViewModel to the UI components. With Declarative UIs, you don’t have such boilerplate code, as the ViewModel and the UI components are fully decoupled.
c

curioustechizen

12/07/2020, 7:14 PM
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.
1
b

birdsofparadise

12/07/2020, 7:26 PM
@curioustechizen I think you are thinking the same thing I did @Daniele B’s is using the
ViewModel
term to mean
Copy code
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'm guessing u have some View-(Presenter/Controller) that handles the platform specific parts of connecting a ViewModel to a View right?
c

curioustechizen

12/07/2020, 7:32 PM
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)
b

birdsofparadise

12/07/2020, 7:46 PM
@curioustechizen For iOS do you write the views in Kotlin itself?
d

Daniele B

12/07/2020, 7:55 PM
@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.
👍 1
c

curioustechizen

12/07/2020, 8:19 PM
@birdsofparadise no. For iOS the views are written in Swift
b

birdsofparadise

12/07/2020, 8:23 PM
@curioustechizen Ah for sure. Do you use SnapKit?
d

Daniele B

12/07/2020, 11:30 PM
I have updated the slides, without referencing the ViewModel, as it can be confusing for someone:
b

birdsofparadise

12/07/2020, 11:30 PM
The term
Controller
might work
At least in the iOS world thats commonly what we call it
The slides are pretty good otherwise
gj 👍
d

Daniele B

12/07/2020, 11:34 PM
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.
j

Joost Klitsie

12/08/2020, 8:19 AM
@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.
but in that sense, yes the coupling is gone 😄 totally agree. Also we don't have to clean up existing views that we don't want anymore (showing/hiding)
which is nice
g

gildor

12/08/2020, 11:51 AM
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
d

Daniele B

12/08/2020, 2:16 PM
@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.
k

Kirill Grouchnikov

12/08/2020, 2:19 PM
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.
☝️ 1
j

Joost Klitsie

12/08/2020, 2:21 PM
@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.
d

Daniele B

12/08/2020, 2:28 PM
I hope these new slides make the point more clear
g

gildor

12/09/2020, 2:31 PM
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
d

Daniele B

12/09/2020, 4:22 PM
@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.
j

Joost Klitsie

12/09/2020, 4:24 PM
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
☝️ 1
d

Daniele B

12/09/2020, 4:28 PM
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.