Composable แบบมีสถานะกับไร้สถานะ

Every Composable is either stateful (it holds its own data) or stateless (it just renders what you pass in). Knowing which is which shapes your whole app.

A stateful Composable remembers something across recompositions, usually with remember. It owns and changes its own data.

A stateless Composable holds no state of its own. It only reads its parameters and draws, so the same inputs always give the same output. 🎯

Stateless Composables are easier to reuse: they fit any screen, in any state, because the caller decides what to show.

Because a stateless Composable just takes parameters, you can feed it sample data in @Preview and see every variation instantly.

Stateless parts are predictable: pass an input, assert the output. No hidden internal data means far simpler tests. ✅

Stateful Composables are convenient for quick demos, but they trap data inside. That makes them hard to share, preview, or control from outside.

See a remember or mutableStateOf inside? It is stateful. See only parameters being read? It is stateless.

A clean pattern: keep one thin stateful wrapper that owns data, and a stateless Composable that only handles how things look.

The stateful wrapper feeds its data into the stateless one. Now the visual part stays pure while the state lives in just one place.

Default to stateless when you build components. Add state only at the spot that truly needs to own it, and no lower.

Which kind of Composable is the easiest to reuse and preview?

Stateful Composables own data; stateless ones just render parameters. Favor stateless components and keep state in one small wrapper. 🚀