A modern programming language that makes developers happier.

kotlinlang

&gt; As a rule of thumb, you should create a view model to hold your state […] when the composable is close to the root of the screen.
&gt; When that’s not the case, for examples, composables that are reusables […], don’t use a view model , instead create a regular state holder class to manage state and expose events.
This is said shortly after 7:32 in the video, the slide at that time refers to a `Carousel` and a `ExpandableCard` but I couldn’t find any related code in the compose-sample project. Does anyone hasve a concrete/sharable example of such a “regular state holder class”?
<https://youtu.be/0z_dwBGQQWQ?t=452>

If I understood it correctly results of all `remember*State()` functions are state holder classes, e.g. `ScaffoldState`, `LazyListState`, etc.

It’s a bit problematic for me since that reusable composable used to get data from an api and/or db though it’s view model :confused: (Imagine a custom row composable displaying different content in each instances) How would you approach that?

<https://kotlinlang.slack.com/archives/CJLTWPH7S/p1618598956479500?thread_ts=1618598414.479200&amp;cid=CJLTWPH7S|This> may help.

The model to think here is that the idea case composable doesn't _get_ data it's _given_ data via params.

Anything that fetches its own data is inherently stateful. When possible it's better to provide a stateless ui display composable and handle state above it

In practice there's a dozen ways to slice this API, but the simplest is to use state hoisting of (param: T, onParamChange: (T) -&gt; Unit)

Mixing state and ui display is generally harder than keeping them separate

I’ve been looking at the projects from compose-samples and saw many screens similar to mine with different sections but the parent screen is the one “containing” all the data for each nested composable. My current logic is based on a fragment that was inserted multiple time inside a parent fragment and each instance were in charge of getting their own data. I guess the approach is inherently different with compose, where the opposite is encouraged :slightly_smiling_face: