> As a rule of thumb, you should create a view model to hold your state […] when the composable i...

# compose

[jean]

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.

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▾

[Albert Chang]

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

[jean]

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 😕 (Imagine a custom row composable displaying different content in each instances) How would you approach that?

[Albert Chang]

This may help.

[Sean McQuillan [G]]

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

[Sean McQuillan [G]]

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

[Sean McQuillan [G]]

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

[jean]

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 🙂

[jean]

thanks for the advices!