Replies: 1 comment
-
Think a general first idea might be at reducing the events to match the different states, trying not to have a singular "Event" type (not necessarily the case here). Next would be splitting any larger state up into smaller sub-states and sort of doing the same thing, associating events with the corresponding state. For a generally large case where you want to mutate a compose state you could encapsulate the method and @Composable
fun composeState() {
val countState = remember { CountState(0) }
when (action) {
is SomeAction -> {
countState.handleSomeAction(action)
}
}
}
@Stable
class CountState(initial: Int) {
private val count = mutableStateOf(initial)
fun count() = count.value
fun handleSomeAction(action: SomeAction) {
count.value++
// do something
if (count.value == action.something) {
count.value += 10
}
}
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm looking at ways to reduce the size of the eventSink lambda passed into the state object. In our current codebase (not using compose state management atm) we delegate action handling to a helper function when there is more than a few lines of logic. For certain screens this is very important because they can have 20+ actions resulting in a huge
when
statement, making things bloated.Is there a suggested pattern for delegating the handling of an eventsink action to a method? The main issue I'm struggling with is how this new method would read/write state.
Beta Was this translation helpful? Give feedback.
All reactions