Qué es una función componible

Una función componible parece una función corriente con una anotación encima, y esa apariencia inocente es el origen de casi todos los malentendidos iniciales. No fabrica objetos, no te entrega la interfaz que acabas de escribir y no puedes guardarla en una variable para pintarla más tarde. Lo que hace es bastante más extraño: al ejecutarse deja un rastro en una estructura de datos que el motor mantiene por debajo, y de ese rastro —no del valor de retorno— nace la pantalla. Entender qué es ese rastro, y qué le hizo el compilador a tu función para que fuera posible, es exactamente la frontera entre escribir Compose y entender Compose.

Describir en vez de construir

En el modelo de vistas clásico, escribir interfaz es fabricar y mutar objetos. Inflas un TextView, guardas la referencia, y cada vez que los datos cambian llamas a setText. El objeto es la fuente de verdad visible y tu trabajo consiste en mantenerlo sincronizado a mano con los datos, sabiendo que cualquier camino que olvides deja la pantalla mintiendo. Ese trabajo de sincronización crece de forma cuadrática con el número de estados posibles, y es donde vive la mayoría de los defectos de interfaz de la última década.

Una función componible invierte el planteamiento. No construye ni conserva nada: describe cómo debe verse la interfaz para unos datos concretos. Cuando los datos cambian, no actualizas la pantalla, sino que Compose vuelve a ejecutar la descripción y calcula por su cuenta la diferencia mínima que hay que aplicar sobre lo que ya existe. La sincronización deja de ser tarea tuya y pasa a ser una propiedad del sistema.

@Composable
fun TarjetaUsuario(nombre: String, conectado: Boolean) {
    Column {
        Text(text = nombre)
        if (conectado) {
            Text(text = "En linea")
        }
    }
}

Fíjate en lo que ese if significa aquí. No es un fragmento de código que decide si crear una vista una vez: es parte de la descripción. Si conectado pasa a ser falso en la siguiente ejecución, la segunda línea sencillamente no se describe, y Compose retira el nodo correspondiente porque ya no forma parte de lo descrito. No hay setVisibility, no hay rama de limpieza, no hay estado intermedio que puedas olvidar. El flujo de control del lenguaje se convierte en el mecanismo de composición de la interfaz, y por eso los bucles, las condiciones y las funciones de Kotlin bastan para expresar jerarquías que en XML exigían inflado dinámico y adaptadores.

De ahí se derivan tres consecuencias que se notan enseguida al escribir. La primera es que desaparecen las referencias a widgets: no hay nada que buscar por identificador ni que guardar en un campo, porque no existe un objeto tuyo al que agarrarte. La segunda es que el número de estados que tu código debe contemplar deja de crecer, porque solo describes el estado actual y nunca las transiciones entre estados. Y la tercera, menos obvia, es que la reutilización cambia de herramienta: donde antes se heredaba de una vista para especializarla, ahora basta con extraer una función y llamarla, porque componer funciones es más barato y más flexible que componer clases.

Qué hace el compilador con tu función

La anotación @Composable no es documentación ni un simple marcador para generar código auxiliar: cambia el tipo de la función y su convención de llamada. Una función componible solo puede invocarse desde otro contexto componible, igual que una función suspend solo puede llamarse desde otra suspend. Es un sistema de efectos, con la misma lógica de contagio: la anotación marca la necesidad de un contexto de ejecución especial, y ese contexto es el que el compilador inyecta.

// Lo que escribes
@Composable
fun Saludo(nombre: String) {
    Text(text = "Hola $nombre")
}

// Lo que genera el plugin, drasticamente simplificado
fun Saludo(nombre: String, composer: Composer, changed: Int) {
    composer.startRestartGroup(0x7f3a91c2)   // clave derivada del sitio de llamada
    // si el parametro no cambio, se salta el cuerpo entero
    Text(text = "Hola $nombre", composer, 0)
    composer.endRestartGroup()?.updateScope { c, _ ->
        Saludo(nombre, c, changed or 1)      // como reejecutarse mas tarde
    }
}

Tres piezas merecen atención. La primera es el parámetro Composer implícito: es el hilo conductor que todas las funciones componibles se van pasando, y el objeto a través del cual se emite. La segunda es la máscara changed, un mapa de bits que indica qué parámetros llegan modificados desde la llamada anterior; sobre ella se apoya la posibilidad de saltarse el cuerpo. La tercera es la clave numérica constante, calculada a partir de la posición del sitio de llamada en el fichero fuente: es la identidad de esa invocación, y no depende de los datos.

Esa última idea es la más contraintuitiva y la más importante. En Compose, la identidad de un fragmento de interfaz no la da un identificador que tú asignas ni el contenido que muestra, sino el lugar del código desde el que se llamó. Dos llamadas a la misma función desde dos líneas distintas son dos elementos distintos y permanentes; la misma llamada ejecutada mil veces es siempre el mismo elemento, aunque cambien todos sus argumentos.

El caso donde la posición no basta es el bucle: si recorres una colección, todas las iteraciones comparten el mismo sitio de llamada y por tanto la misma clave, así que el runtime las distingue por el orden en que aparecen. Mientras la colección solo crece por el final funciona; en cuanto insertas o reordenas, la correspondencia se descoloca y el trabajo memorizado migra al elemento equivocado. Para eso existe la función key, que envuelve un tramo de composición y le da una identidad explícita derivada de tus datos, no de la línea del fichero.

@Composable
fun ListaArticulos(articulos: List<Articulo>) {
    Column {
        articulos.forEach { articulo ->
            key(articulo.id) {          // identidad de dominio, no de posicion
                FilaArticulo(articulo)
            }
        }
    }
}

El árbol invisible

Ahora se puede responder a la pregunta que todo el mundo hace al principio: si describe la interfaz, ¿por qué devuelve Unit? Porque el resultado no viaja por el valor de retorno, sino por el Composer. Al ejecutarse, la función abre y cierra grupos y emite nodos en una estructura llamada tabla de ranuras: un búfer lineal, con hueco móvil, donde cada grupo ocupa un tramo contiguo y guarda tanto la clave de posición como los valores recordados en ese punto. Recorrerla es recorrer la ejecución de tu código convertida en datos.

flowchart TD
A[Funcion anotada con Composable] --> B[El plugin inserta Composer y claves de posicion]
B --> C[Al ejecutarse abre grupos y emite en la tabla de ranuras]
C --> D[El runtime calcula la diferencia con la version anterior]
D --> E[Un Applier materializa el arbol de nodos de layout]
style A fill:#a6e3a1,color:#11111b
style E fill:#89b4fa,color:#11111b

Si la función devolviera un objeto de interfaz, cada ejecución produciría una jerarquía nueva y habría que compararla entera contra la anterior, que es el modelo del árbol virtual de la web. Compose evita ese coste porque no hay árbol intermedio que comparar: la ejecución escribe directamente sobre la tabla existente, sabe en qué ranura está gracias a las claves y solo anota lo que difiere. Devolver Unit no es una limitación de la que haya que disculparse: es la condición que permite que la memorización sea posicional y que la actualización sea incremental por construcción.

Conviene además separar dos capas que suelen confundirse. El runtime de Compose no sabe nada de Android: gestiona grupos, memorización y cambios sobre un árbol genérico. Quien traduce esas emisiones en nodos concretos es un Applier, y el de la interfaz de Android produce nodos de layout. Por eso el mismo runtime puede pilotar gráficos vectoriales, widgets del escritorio con Glance o, en principio, cualquier árbol mutable. Tu función no habla con vistas: habla con un runtime de composición que resulta estar conectado a ellas.

El contrato que firmas

Aceptar esa firma implica aceptar unas reglas. No son estilo ni buenas maneras: son las precondiciones que el runtime da por ciertas para poder saltarse, reordenar, abandonar o repetir tu función sin avisarte.

Conviene además notar de dónde sale el contagio de la anotación. Como @Composable forma parte del tipo, una lambda que quieras invocar desde dentro de una composición tiene que estar anotada también, y por eso los componentes que reciben contenido declaran su parámetro como una función componible. Ese detalle de tipos es el que permite el patrón de ranuras: en lugar de configurar un componente con veinte parámetros de aspecto, le pasas el contenido que debe emitir y él decide dónde colocarlo. Toda la biblioteca de Material está construida sobre esa idea, y es la razón de que se pueda extender sin heredar de nada.

Hay un corolario práctico que ahorra muchas discusiones de revisión de código: una función componible que devuelve algo distinto de Unit no está describiendo interfaz, está calculando un valor, y casi siempre debería ser una función normal. Y una función que emite interfaz no debería además devolver datos al que la llamó, porque mezcla dos naturalezas que el modelo mantiene deliberadamente separadas.