Question about `mutableState` and `State` in the Using State

Question

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`

Lauren Yew · Answer

< jim> Can you elaborate on liveness What do you mean

Sam · Answer

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 ```

Sam · Answer

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

Sam · Answer

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

jim · Answer

< Lauren Yew> 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

Lauren Yew · Answer

got it thank you

Adam Powell · Answer

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

Adam Powell · Answer

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

Adam Powell · Answer

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

Colton Idle · Answer

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

Adam Powell · Answer

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