Qué es el STATE HOISTING

El State Hoisting es un patrón de diseño que nos indica que el estado hay que elevarlo.

Es decir, tiene que venir dado.

Si por ejemplo, estamos en una función, el estado tiene que venir pasado por parámetro.

Esto está genial, porque nos permite que esta función sea stateless.

Que no tenga estado.

Que sea inmutable.

No en vano, el concepto de state hoisting está muy vinculado a la programación funcional.

Y como podrás imaginar, esto es muy bueno de cara al testing. Ya que para ciertos inputs, obtendremos ciertos outputs.

Y yendo un poco más allá, tenemos que pensar que para seguir este patrón, los estados van hacia abajo… y los eventos hacia arriba.

Algo que las lambdas resuelven de maravilla.

De este modo, hacemos que un componente visual en Jetpack Compose se encargue de lo que se tiene que encargar, que es de la parte de UI y no de la lógica de dominio.

Por lo que un buen ejercicio, es que cuando tengas un remember en una función en Jetpack Compose, pienses si podrías sustituirlo por pasarle un parámetro. Por subir el estado.

Te pongo un ejemplo.

Esto sería sin elevación de estado:

@Composable
fun MainScreen() {
    MutableBooleanScreen()
}

@Composable
fun MutableBooleanScreen() {
    val boolean = rememberSaveable { mutableStateOf(true) }
    Column {
        Button(
            onClick = {
                boolean.value = !boolean.value
            }
        ) {
            Text(text = "Click")
        }
        Text(text = boolean.value.toString())
    }
}

Y esto, elevándolo:

@Composable
fun MainScreen() {
    val boolean = rememberSaveable { mutableStateOf(true) }
    ImmutableBooleanScreen(boolean.value) {
        boolean.value = !boolean.value
    }
}

@Composable
fun ImmutableBooleanScreen(
    boolean: Boolean,
    onClick: () -> Unit,
) {
    Column {
        Button(
            onClick = {
                onClick()
            }
        ) {
            Text(text = "Click")
        }
        Text(text = boolean.toString())
    }
}

Como ves, ImmutableBooleanScreen ya no tiene estado. Simplemente se encarga de la parte visual.

De esta manera, se va a poder reutilizar código de un modo más óptimo. Por ejemplo, teniendo una SSOT (Single Source Of Truth) para compartir estado. Lo cual es una muy buena opción para tener apps más robustas.

Además, imagínate que en este ejemplo, ese booleano lo quisiéramos usar en otro composable. Menudo follón sería sin elevar el estado… 😅

Te dejo por aquí la documentación oficial que habla sobre dónde elevar el estado.

Aunque esto te lo haya puesto como ejemplo para Compose, también hay que tener en cuenta, que nos puede servir de ayuda para muchos otros casos en los que nos interese extraer la mutabilidad. Lo cual suele ser muy buena idea por norma general.