Is nesting state considered bad practice? I have a...

# compose

[Jonathan]

Is nesting state considered bad practice? I have a UI state holder (data class) that represents an entire screen. My screen contains a LazyColumn of that can/will be updated frequently (several times a second). This list is currently backed by List<String> that is a property of my UI state holder class that I update using .copy(feed = …) .
I don’t believe this to be very optimal and would cause excess recompositions because my UI state holder is changing frequently, even though its just the list property changing. I think using mutableStateListOf<String>(...) would be the better choice. What I’m unsure of is the best way to present this new state to my UI. Is it optimal to nest compose state objects such that I’d just replace the List<String> type with SnapshotStateList<String>?
Furthermore, this type is mutable and I was under the impression that exposing mutable state outside of it’s owner/manager is bad practice. I don’t see a StateList<State> that I could use to expose an immutable reference to state like the singular State<T> observer.
I could always keep the mutable list state separate from the overall screen UI state holder but I’d like to keep all screen UI state together if possible.

[Pablichjenkov]

My experience with ListT is that is extremely inefficient and verbose to make copies all the time for simple cells inner data updates. So I found out mutableStateListOfT fits better for a state that represents a collection.

[Jonathan]

Do you recommend holding the mutableStateList inside of my overall screen ui state holder or keep it separate?

[Pablichjenkov]

Inside, although reading your question again. I think you can keep the actual instance in the ViewModel and just reference from your state/substate/nested-state instance. I don't think it matters much. In the ViewModel is easier to apply mutations on it.