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
==?) -
state()andstateFor()might be going away, to steer developers towards usingremember()explicitly
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
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 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!