Html.lazy: no recalcular una vista cuando sus entradas no cambian, y los requisitos exactos

Hay optimizaciones que fallan ruidosamente y optimizaciones que fallan en silencio, y las segundas son mucho peores. Envolver una función de vista con lazy pertenece a la segunda categoría: si se cumplen sus condiciones, el runtime devuelve el árbol memorizado sin evaluar nada y la comparación se salta esa rama entera; si no se cumplen, el código compila igual, se comporta igual, produce exactamente la misma interfaz, y lo único que ocurre es que la función se evalúa cada vez y además se paga el coste añadido de guardar y comparar referencias inútilmente. No hay error de compilación, no hay advertencia, no hay traza en la consola. El resultado es un ecosistema lleno de llamadas a lazy que no memorizan nada y de programadores convencidos de haber optimizado su interfaz. La causa de este desajuste es que el contrato de la envoltura no se lee en su firma sino en su implementación: la firma promete el mismo tipo que la función original, y la condición real —qué significa que dos argumentos sean los mismos— vive en una decisión de implementación que hay que conocer. Esta lección la expone completa, deriva de ella los requisitos exactos y termina con el procedimiento para verificar que se están cumpliendo.

Qué guarda exactamente la envoltura

Una llamada envuelta no produce un árbol: produce un nodo de una forma especial que guarda tres cosas, la función, los argumentos con los que se la iba a llamar, y —una vez evaluada— el árbol que resultó. En el dibujado siguiente, cuando la comparación llega a esa posición y encuentra dos nodos perezosos, no baja a compararlos: compara la función del nodo viejo con la del nuevo y cada argumento con el suyo. Si todos coinciden, adopta el árbol ya calculado del nodo anterior y da por terminada la rama sin ejecutar una sola línea de la función de vista. Si alguno difiere, evalúa la función nueva y compara el resultado con el árbol anterior de la forma habitual.

El ahorro es doble y conviene separarlo porque no siempre se aprecia el segundo componente. Se ahorra la construcción de la descripción, que en una sección grande son miles de objetos reservados y descartados; y se ahorra la comparación de esa descripción con la anterior, que es un recorrido de la misma magnitud. En una lista de mil filas donde nada relevante cambió, la diferencia entre pagar los dos recorridos y pagar una comparación de dos referencias es exactamente la razón por la que existe esta herramienta.

import Html.Lazy exposing (lazy, lazy2, lazy3)


view : Model -> Html Msg
view model =
    div []
        [ lazy cabecera model.usuario
        , lazy2 panelTareas model.filtro model.tareas
        , lazy pie model.version
        ]


-- Existen variantes hasta ocho argumentos: lazy, lazy2 ... lazy8

Los requisitos exactos, uno a uno

La comparación de la función y de los argumentos se hace por identidad de referencia. Para los valores primitivos eso coincide con lo que uno espera, porque dos números iguales, dos cadenas iguales o dos booleanos iguales son indistinguibles para esa comprobación. Para todo lo demás —registros, listas, uniones con datos, diccionarios, tuplas— la comprobación exige que sea literalmente el mismo objeto en memoria, no uno con el mismo contenido. De esa única regla salen todos los requisitos, y por eso conviene enunciarlos como consecuencias y no como una lista arbitraria que memorizar.

El primero afecta a la función. Debe ser un valor definido en el nivel superior del módulo, porque solo entonces su referencia es la misma en cada dibujado. Una lambda escrita en la llamada se construye de nuevo cada vez y falla siempre; una función definida dentro de un let de la vista, igual; y una aplicación parcial hecha en la llamada, también, porque aplicar parcialmente construye un cierre nuevo. Este último caso es el que más engaña, porque parece idéntico a pasar una función y no lo es.

El segundo afecta a los argumentos. Deben ser primitivos o referencias que sobrevivan intactas entre dibujados, lo cual significa en la práctica campos que se leen directamente del modelo. Fabricar el argumento en la llamada —un registro de configuración, una lista construida con List.map, una tupla, un valor filtrado— produce un objeto nuevo cada vez y desactiva la memoización con total seguridad. Si hace falta transformar los datos, la transformación tiene que ocurrir dentro de la función envuelta, no antes de entrar en ella.

-- Falla: la lambda es nueva en cada dibujado
lazy (\ts -> panelTareas model.filtro ts) model.tareas

-- Falla: aplicar parcialmente construye un cierre nuevo
lazy (panelTareas model.filtro) model.tareas

-- Falla: el registro se construye aqui mismo
lazy panel { titulo = "Tareas", items = model.items }

-- Falla: la lista es nueva aunque su contenido sea igual
lazy panelTareas (List.filter .activa model.tareas)

-- Funciona: funcion del modulo y argumentos tomados del modelo
lazy2 panelTareas model.filtro model.tareas

El tercer requisito no es una condición de corrección sino de eficacia, y es el que más rendimiento decide. Como una actualización de registro produce un registro nuevo, pasar el modelo completo a una función envuelta garantiza que la memoización se descarte en cuanto cambie cualquier campo, incluso uno que la sección envuelta no mire. Pasar los dos o tres campos concretos que la función necesita, usando la variante numerada correspondiente, hace la comparación a la vez más barata y más certera. Esta disciplina tiene un efecto colateral que compensa por sí solo aunque el rendimiento no mejore: obliga a declarar de qué depende realmente cada sección de la interfaz, y esa declaración suele descubrir dependencias accidentales que nadie había advertido.

Cuándo compensa y cómo comprobar que se aplica

La envoltura no es gratuita: guarda referencias, añade una forma de nodo más al árbol y paga una comparación en cada dibujado, además de mantener vivo el árbol memorizado en memoria mientras el nodo exista. Aplicada a una función barata, el remedio cuesta más que la enfermedad y el código queda peor sin ganancia mensurable. La regla es envolver secciones cuya evaluación sea sustancial y cuyas entradas cambien con menos frecuencia que el modelo en conjunto, que es justo la combinación en la que el ahorro es grande y el acierto probable.

flowchart TD
D[Comparacion llega a un nodo perezoso] --> F[Misma funcion por referencia]
F -->|No| E[Evaluar la vista de nuevo]
F -->|Si| G[Comparar los argumentos]
G -->|Alguno distinto| E
G -->|Todos iguales| R[Reutilizar el arbol memorizado]
R --> S[Rama saltada por completo]
E --> C[Comparar el arbol resultante]
style G fill:#89b4fa,color:#11111b
style R fill:#a6e3a1,color:#11111b
style S fill:#cba6f7,color:#11111b

Hay además una consideración de memoria que rara vez se menciona. El árbol memorizado permanece vivo mientras el nodo perezoso exista, de modo que envolver cientos de secciones grandes mantiene en memoria cientos de descripciones completas que en otro caso se habrían recolectado enseguida. En una aplicación de escritorio eso no se nota; en un dispositivo con poca memoria, sí, y el síntoma es desconcertante porque la interfaz va fluida hasta que empieza a ir a saltos por presión del recolector. La regla que evita el problema es la misma que evita el desperdicio: envolver pocas secciones y grandes, nunca muchas y pequeñas.

Comprobar que surte efecto no admite conjeturas y es fácil. El método directo consiste en dejar temporalmente una traza en la función envuelta y ver si deja de aparecer cuando cambian partes del modelo ajenas a ella; recuerda que esa traza debe retirarse antes de compilar en modo optimizado, porque las funciones de depuración están prohibidas allí. El método definitivo es el perfilador del navegador: se graba una interacción representativa, se localiza la función en el desglose de tiempo y se confirma que su número de invocaciones cae. Si no cae, el fallo está en la lista de requisitos anterior y casi siempre es el segundo o el tercero.

Cómo convive con el resto del árbol

La memoria de un nodo perezoso vive en el árbol y no en un registro global, lo cual tiene una consecuencia que explica muchos fracasos aparentemente inexplicables: si el nodo padre se sustituye, el nodo perezoso desaparece con él y la próxima evaluación no encuentra nada que reutilizar. Basta con que un ancestro cambie de etiqueta según una condición para que toda la memoización que hubiera por debajo se pierda en cada cambio de esa condición. Antes de investigar los argumentos conviene por tanto comprobar que la posición del nodo en el árbol es estable.

La combinación con listas con clave sigue la misma lógica y admite dos disposiciones que no son intercambiables. Envolver la función que produce el contenedor entero evita reconstruir la descripción de la lista cuando ni el filtro ni los datos han cambiado, y es lo apropiado cuando la lista se recalcula por motivos ajenos a ella. Envolver la vista de cada fila, en cambio, permite que una modificación de un solo elemento deje intactas las descripciones de las demás, y es lo apropiado cuando las filas son costosas y cambian de una en una. Aplicar las dos a la vez es legítimo y frecuente.

-- Capa exterior: evitar reconstruir la lista entera
lazy2 listaTareas model.filtro model.tareas


-- Capa interior: cada fila decide por su cuenta
conClave : Tarea -> ( String, Html Msg )
conClave tarea =
    ( String.fromInt tarea.id, lazy fila tarea )


-- Pasar constructores como etiquetadores: son valores estables del modulo
Html.map DesdeTabla (lazy tabla model.datos)