One Off the Slack: The Changing State of State
In a discussion about state management, Google’s Leland Richardson indicated that:
The default policy for determining changes in state is switching from referential (i.e., are they the same object?) to structural (i.e., are they
stateFor()might be going away, to steer developers towards using
Zach Klippenstein then asked about
savedInstanceState(), and Leland made the
just a reminder that
Zach also expressed concern over the demise of
stateseems 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
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