Daniele B
12/05/2020, 1:56 PMJoost Klitsie
12/05/2020, 2:34 PMDaniele B
12/05/2020, 2:44 PMJoost Klitsie
12/05/2020, 2:58 PMDaniele B
12/05/2020, 3:15 PMJoost Klitsie
12/05/2020, 3:19 PMDaniele B
12/05/2020, 3:23 PMI do not think passing domain objects to a view is the best thing to doit’s just data, strings, already formatted, and ready to be displayed on the UI layer. The formatting is done in the shared ViewModel.
But talking about apis, we use on my project (like at my work, not kmp) we also download data objects, nothing in the api is architected to serve specific screensOf course, in many cases it’s important to apply client-side logic, even if the client-logic is not shared and needs to be replicated for each platform. But that comes with a cost (of replication). In KMP, there are not costs of replication, so such client-side logic can be very extensive. And many advanced things can be done to improve the user experience. At no cost.
Joost Klitsie
12/05/2020, 3:28 PMDaniele B
12/05/2020, 3:32 PMWell that means some coupling right? The viewmodel has to poop out the data such that the view can display it. I mean it does have less coupling if you dont have to worry about the imperative view, but still its something
UI Components in the imperative (view-based) UI systems have IDs. When I talk about coupling, I mean that the ViewModel (which is not the same as saying the Android's ViewModel component) needs to link data to each UIcomponent ID. This happens in both Android and iOS, view-based system. In a KMP/MVI/DeclarativeUIs project, the ViewModel can be totally decoupled in the sense that it doesn't need to link data to UI components. It just provides the app state (which is a data object), and it's up to the declarative UI layer to use it in the way it wants.
Joost Klitsie
12/05/2020, 8:02 PM