A modern programming language that makes developers happier.

kotlinlang

Question about `mutableState` and `State` : in the "Using State in Jetpack Compose" codelab, it says:
```State&lt;T&gt; is intended to be used by Compose.

Application state that's used outside of Compose should not use State&lt;T&gt; to hold the state.```
Why is this? Is `State` being discarded along with the compose-recompose lifecycle or something?
Does anyone know the lifecycle of `State`?

<@U6158UG1Z> Can you elaborate on "liveness"? What do you mean?

Our app uses redux like state tree to store all of our state as the source of truth. We connect portions of that state tree to components wherever we need with hooks that we wrote, e.g.
```val conversations = store.mutableSubscribedStateOf({ it.conversations.dms })```

works quite well, as any component will receive live updates whenever the redux state tree is updated, but only for that branch of the state

so re-renders only occur as needed, and you don’t find yourself with all the state at the top of your component hierarchy causing rerenders all the way down your entire app

<@U01GXEV7HBM> Suppose you wanted to have a state object that consumes a flow and exposes it as an observable that can be automatically subscribed by Compose, and store that field on an object or global or ambient or whatever. But suppose the flow it was consuming was expensive (like, required the GPS to be turned on and thus drains battery, or requires subscriptions across a network to a database layer). State objects generally do not know when they are alive (being read from), so they don't know when they need to be monitoring their data sources for updates. When you are architecting a backend data model, the liveness of dataflows are an example of something to take into consideration, and currently can be better handled by other data libraries that are built to handle such things. It is just one of many considerations to take into account when choosing a data layer. The point is that State is simple and interoperates nicely with Compose, but it isn't designed to be full fledged data layer.

There's ongoing discussion among the compose engineering and developer advocacy teams around when to offer cut and dry, "use A for X, use B for Y" recipes vs. when to present several options and describe the tradeoffs. The specific wording from this codelab is from the former school of thought. :slightly_smiling_face:

this is partially in reaction to historical android development challenges and feedback, where we tended toward the other extreme of presenting a toolbox with little to no opinionated default guidance

fwiw I tend to agree with Jim above - I think there are plenty of places to use classes made up of `mutableStateOf`-backed properties and `snapshotFlow {}` or other snapshot APIs to observe changes at the fringes of or even entirely outside of a UI layer, but the codelab's advice will also get you to a clean, working app with fewer decision points

Recipes with pros and cons would be great for those of us getting used to this and seeing "theres soooo many ways to do this" and getting overwhelmed. :smile:

Yep, hence why the codelabs tend to lean that way. Once you get curious enough to ask the question, that's a better time for the toolbox tradeoff material :slightly_smiling_face: