What's the best way to architect if I have some of...
# compose-desktop
a
What's the best way to architect if I have some of my state that's dynamically refreshed from the db and the presenter class (sql delight / flows), and some of my state that's not externally refreshed (e.g. view scrolling state / mutablestate variables). I feel it's kinda conflicting because I would like to just recreate a immutable data holder with data from the db every time, but maintain the state class with e.g. scrolling state over time. I could use separate classes and a separate argument in the Composable, but sometimes these datas have an interplay, e.g. zooming around the data, I need to access the data sourced from the db for that. In that case, should I just keep everything in one class? Basically I just feel like the state flow from the db makes things awkward, because of having to call collectAsState() in the composable I'm using molecule in the presenter class by the way