Hello All! I have a question about state hoisting. Based on the docs and recent videos aiming for st...

# compose

[Marco Pierucci]

Hello All!
I have a question about state hoisting.
Based on the docs and recent videos aiming for stateless composables should be the way to go. State is recevied as a function param and we transmitted through lambas.
I find this quite compelling but am currently working on a rotationary dial. Within I have so inner state ( texture angle, gesture angle, pointer info etc). Does it makes sense to push for a stateless component on this scenario? It feels weird that my domain layer needs to be aware of such thing

[Zach Klippenstein (he/him) [MOD]]

You can create two – a stateless one that does the actual rendering and event handling, and an stateful one that provides a simpler API but manages the state itself.

[Zach Klippenstein (he/him) [MOD]]

You can also make the state an optional parameter. E.g.

@Composable fun RotaryDial(
  modifier: Modifier = Modifier,
  rotaryState: RotaryState = remember { RotaryState() },
  …
)

class RotaryState() {
  …
}

[Marco Pierucci]

Ok yes that makes sense, although I still have a composable with state. ( I dont real it mind it, its just that it really fees form the cos that I should be avoiding it)

[Gabriel]

I think it's ok to have some local state in composable as long as you pick the right place for it, having a simple higher component that handles that local state and just passed it to the more complex lower component is a reasonable compromise?

[Zach Klippenstein (he/him) [MOD]]

Yea, components are allowed to have their own state and there are cases where that makes sense (look at TextField, for example).