Hey! I need a bit a of heads up from experienced c...

# compose-desktop

[redenergy]

Hey! I need a bit a of heads up from experienced compose users. So, I have a pretty large desktop application with lots of screens (=views), about 150 total. We're hoping to start gradual migration to Compose and I am playing around with it to figure out how views should be architectured.

Usually you'll have some kind of storage for data which is used in the UI, depending on the architure pattern it is often called Model or something like that. Additionally, you'll have something which performs actual logic of the UI, it can be called a Controller, or something similiar to that. And of course you have a View, something which defines the visuals of the UI and it's presentation. Depending on the approach (MVC/MVVM/MVA/etc) these entities can be called and organized differently but in the end you have a data, which can be operated upon in some way, and presented to the user somehow.

Most of our current UI is written in such a way, that data and all UI logic is kept in a single class, which nicely encapsulates whole UI state and operations. We would like to continue doing our UIs the same way - it is familiar to all our developers and also will simplify things during the migrations process.

Now to my question, while skimming through various examples and playing with compose a bit I found it difficult to figure out how to organize 'Model' and 'Controller' in a single class. I don't have much experience with jetpack on Android, but the thing I am looking for seems to be usually referred as ModelView. However, I can't find any good examples of ModelView in compose for desktop application thus I can't really understand if it actually the thing which would suit our goals.
- Are there any good, bite-sized examples of ModelView pattern with compose for desktop application?
- If ModelView approach is not actually the thing I am looking for, what would be the best approach to encapsulate business logic and UI state in a single class while allowing it to freely communicate with external systems of the application?

[Landry Norris]

I’ve always kept my state in a data class, and had a class that had all the methods my UI could call. It would hold a StateFlow<FooState> that could be observed. I find this to be really manageable. I usually keep them in the same file.

[Landry Norris]

If you want everything to completely be in one class, you’d have to make sure all your state variables are either MutableStateFlow or MutableState so Compose can know when any property changes.

[mcpiroman]

As long as mutable data is reactive (`mutableStateOf`or StateFlow, but I'd advice to stick with the former whenever possible), the rest does not matter for Compose. You may have your view model classes however you like; the `ViewModel`class is Android specific, CfD does not have it and does not impose any architecture.

[redenergy]

Thank you for the replies. I did some prototyping and it turned way easier when I thought it would be. Basically, all of the Composables in my ui will accept owning Screen as a parameter and it will store whole ui state and expose ui functions. Perhaps I was overthinking this problem too much :)

[Yogeshvu]

@redenergy would be good if you could create a demo example of your implementation and update it here for me and others 🙂