One Off the Slack: The Changing State of State

In a discussion about state management, Google’s Leland Richardson indicated that:

Zach Klippenstein then asked about savedInstanceState(), and Leland made the analogy:

just a reminder that state : savedInstanceState :: remember : rememberSavedInstanceState

Zach also expressed concern over the demise of state():

TBH, even state seems so common and small that I’m a little disappointed to see it go away, although I completely understand the desire to minimize the amount of magic and the API surface, and this is probably a lot simpler to educate.

As Leland pointed out, the problem is that remember() is the real fundamental API, teaching Compose what to… well, remember. state() is simply a convenience function for remembering a mutableStateOf(), but one that hides both the remember() and the mutableStateOf() facets, and those are useful individually as well as in combination.

Part of this is simply to make sure that future developers can understand the composables created by today’s developers. Or, as Leland put it:

i think for a composable function to be understandable, its somewhat important to be able to identify which objects are “remembered” across recompositions and which ones aren’t

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!