Desplazamiento Virtual Rápido y Flexible con Programación Funcional

♪♪ Hola, soy Adam, y bienvenidos a mi charla sobre desplazamiento virtual. Hoy vamos a implementar una lista con desplazamiento virtual básico desde cero, luego hablaremos sobre las mejoras que podemos hacer para aumentar la flexibilidad y usabilidad de la lista, y luego haremos que la lista sea lo más rápida posible. Esta charla te ayudará a entender cómo funciona el desplazamiento virtual y podría ayudarte a obtener unos cuantos fotogramas por segundo más, incluso si estás usando una biblioteca. Así que empecemos.

Para cada viewport desplazado, virtual o no, hay dos partes clave. Un elemento de viewport exterior que tiene una altura, y un elemento interior o lista de elementos que tiene una altura mayor. Si fuera más corto, no habría necesidad de desplazarse, por supuesto. Las listas desplazadas tradicionales renderizan todos sus elementos en el DOM, incluso aquellos que no son visibles, lo que puede causar retraso tanto al renderizar esa lista inicialmente como al desplazarse. El desplazamiento virtual, por otro lado, solo renderiza los elementos que se están viendo en ese momento. Esto nos ayuda a mejorar tanto la carga inicial de la página como el rendimiento del desplazamiento. Usualmente, cuando el tamaño de tu lista alcanza los tres dígitos, es momento de empezar a pensar en el desplazamiento virtual, dependiendo de cuánto tiempo tome renderizar tus elementos individuales. Así que echemos un vistazo a cómo desplazar virtualmente una lista.

Primero, hagamos un producto mínimo viable súper básico. Para esto, voy a asumir que todos los elementos de la lista tendrán la misma altura, pero volveremos a esto un poco más tarde. Para desplazar algo virtualmente, en realidad solo necesitamos calcular tres cosas. Uno, ¿qué tan alto es lo que estamos renderizando? Dos, ¿qué elementos en la lista deberían ser renderizados? Y tres, ¿qué tan abajo dentro del elemento interior deberíamos renderizarlo para que se alinee con el viewport? Para calcular estas tres cosas, vamos a necesitar tres piezas de datos del DOM. Primero, la altura del viewport. Autoexplicativo. Luego, necesitamos la posición de desplazamiento, que es la distancia desde la parte superior del viewport hasta la parte superior del elemento interior. Podemos obtener esto de la propiedad scroll-top del viewport. Finalmente, necesitaremos la altura de un elemento individual en la lista, inclusivo de bordes y márgenes. Todos tienen el mismo tamaño en este ejemplo, así que eso es bastante fácil. Ahora vamos a codificarlo.

Así que lo primero que necesitamos calcular es la altura total de lo que estamos renderizando, que establecemos como la altura del elemento interior. El navegador no puede hacerlo por ti como en el desplazamiento tradicional porque no estamos renderizando todos los elementos a la vez. Así que para nuestra lista básica, podemos establecerlo como la altura de un elemento multiplicada por el número de elementos. Luego, necesitamos determinar qué elementos estamos renderizando. Para esto, necesitamos la altura del viewport y la posición de desplazamiento dentro del viewport. A partir de eso, el índice del primer elemento que queremos renderizar es el piso de la posición de desplazamiento dividida por la altura de cada elemento.

Así que ahora nuestro código se verá un poco así. Solo renderizamos los elementos desde nuestros índices de inicio hasta fin, y para reaccionar al desplazamiento, simplemente podemos usar algún estado reactivo. La altura del viewport se puede hacer con un ref, que no estoy mostrando aquí.

Por supuesto, no queremos renderizar todos estos elementos al principio del elemento interior todo el tiempo. Ahora necesitamos mover los elementos de la lista hacia abajo a la parte del elemento interior que se está mostrando en el viewport. Afortunadamente, eso es fácil. Tradúcelo por el índice de inicio multiplicado por la altura de los elementos de la lista. Hecho. Eso es todo lo que necesitas para tener una lista con desplazamiento virtual funcional. El código cabe en una diapositiva.

Hay algunos puntos que podemos mejorar para hacer la lista más flexible para trabajar, sin embargo, y mejorar la experiencia del usuario al desplazarse por la lista. Así que echemos un vistazo a eso ahora. La mayor limitación es que todos los elementos tienen que ser de la misma altura. Así que vamos a solucionar eso. Para soportar alturas variables de los elementos, lo principal que necesitamos cambiar es nuestro método de encontrar los primeros y últimos elementos para renderizar. En lugar de hacer una división básica, primero necesitamos calcular la suma acumulativa de las alturas de nuestros elementos de la lista. Luego, para calcular nuestro índice de inicio, tomamos nuestra posición de desplazamiento y encontramos el índice del número más grande que es menor que nuestra posición de desplazamiento en nuestras alturas acumuladas. El índice de ese número es nuestro índice de inicio. Para el índice de fin, queremos hacer algo similar. Queremos tomar nuestra posición de desplazamiento más la altura de nuestro viewport, luego encontrar el número más pequeño que es mayor que esa suma en nuestras alturas acumuladas.

El índice de ese número es nuestro índice de fin. Eso podría sonar como mucho, pero podemos hacerlo con una búsqueda que devuelve tanto los índices alrededor del número que estamos buscando. Para esto, el desplazamiento de transformación se convierte en la altura acumulada en nuestro índice de inicio, y la altura total del elemento interior se convierte en la suma simple de todas las alturas de nuestros elementos de la lista. Hecho. Por supuesto, esto asume que la lista de alturas de los elementos puede ser calculada antes de renderizar. Algunas bibliotecas te permiten estimar la altura de los elementos, y luego las medirán una vez que se hayan renderizado realmente y actualizarán en consecuencia. Personalmente, no me gusta este enfoque porque causa scrolljank cuando las estimaciones están equivocadas de una manera que se complica, y en la mayoría de los casos que he encontrado, puedes encontrar una manera de pre-calcular las alturas de los elementos. Sin embargo, si estás construyendo algo como un newsfeed, definitivamente es un enfoque que puedes usar.

Así que ahora que lo hemos hecho un poco más flexible para nuestros diseñadores y desarrolladores, hagamos que la UX sea un poco mejor. En el mundo real, los elementos de la lista pueden tardar un tiempo en renderizarse, y si el usuario se desplaza más rápido de lo que una lista puede renderizar normalmente, los elementos pueden comenzar a parpadear alrededor de los bordes a medida que el viewport avanza más allá del último elemento, solo para que un nuevo último elemento aparezca unos milisegundos después dentro de la vista del usuario. Esto no es una gran experiencia de usuario, y casi todas las bibliotecas de desplazamiento virtual intentan resolver esto renderizando algunos elementos adicionales antes y después del viewport para absorber esa latencia. Esto no es una solución increíble, porque un desplazamiento sostenido a alta velocidad seguirá retrasando la renderización, y aumenta el número de elementos que necesitamos renderizar y volver a renderizar, lo cual es contrario a todo el punto del desplazamiento virtual. Dicho esto, simplemente ir más rápido no siempre es factible, por lo que los buffers pueden ayudar a suavizar las cosas.

He visto muchas bibliotecas de desplazamiento virtual expresar esto en términos de elementos de lista adicionales para renderizar por encima y por debajo del viewport, pero en realidad no creo que ese sea el enfoque correcto en todos los casos. Acabamos de modificar nuestro código para soportar alturas de elementos variables, por lo que no deberíamos asumir que cinco elementos, por ejemplo, en cada dirección es el número correcto en cada posición de la lista. Si son pequeños, podríamos querer renderizar más para darnos más espacio de buffer, y si son grandes, renderizar un número fijo podría estar dejando rendimiento sobre la mesa. Tiene mucho más sentido para mí proporcionar una longitud de buffer en píxeles y luego renderizar tantos elementos como sea necesario para llenarlo. También he escuchado rumores en línea sobre variar dinámicamente la asignación y longitud del buffer dependiendo de la dirección y velocidad del desplazamiento. Y eso, para mí, suena como una forma plausible de optimizarlo también.

Ahora que la lista tiene un mejor UX y más flexibilidad para desarrolladores y diseñadores, podemos aprovechar algunos conceptos de programación funcional para que el desplazamiento alcance tasas de fotogramas más altas también. Así que primero, eliminemos lo fácil. No hay razón para volver a calcular algunos de los valores intermedios relacionados con nuestro soporte de altura variable en cada fotograma, como la suma acumulativa de las alturas de los elementos de la lista. Podríamos simplemente trazar eso en una variable en algún lugar, pero memorizarlo es mucho más fácil y asegura que no podamos romper nuestra lista al olvidar actualizarlo en algún lugar. Solo asegúrate de que la caché tenga tamaño uno y que la lista se compare por puntero. Las alturas no deberían cambiar con frecuencia, por lo que esto es básicamente rendimiento gratuito cuando estás desplazándote. Lo mismo ocurre con cosas relacionadas con la aplicación. Si tienes una tabla desplazada virtualmente, asegúrate de no volver a calcular la ordenación y el filtrado en cada fotograma. La memorización es básicamente gratuita en términos de carga cognitiva, y puede ayudar mucho en estas situaciones donde tus props no están cambiando, pero estás volviendo a renderizar con mucha frecuencia. Además, podemos asegurarnos de que estamos usando las versiones más optimizadas de las subrutinas posibles. Si eres como yo y escribes todo en un estilo funcional, podrías estar dejando algo de rendimiento sobre la mesa al calcular tu suma acumulativa de alturas. Si lo haces en un reduce, estás poniendo mucha presión en tu recolector de basura. Mientras la API se mantenga funcional, puedes escribir la función en un estilo imperativo, y solo deberías necesitar asignar una vez para eso. Además, podemos usar una búsqueda binaria para encontrar los índices de inicio y fin de la lista. Sin embargo, a diferencia de una búsqueda binaria estándar, en lugar de no devolver nada si la aguja no se encuentra en el pajar, en su lugar devolvemos el valor más cercano que, en el caso del índice de inicio, es menor que la aguja, o en el caso del índice de fin, es mayor. Esto lleva el rendimiento asintótico de la búsqueda a log n. A continuación, echemos un vistazo a algunas optimizaciones relacionadas con el DOM para hacer que el desplazamiento virtual sea más rápido. Para esto, a veces no nos importa que un usuario pueda ver todo un elemento de la lista cuando se desplaza. Y si el rendimiento del desplazamiento es de suma importancia, podemos retrasar la renderización de las partes costosas del elemento de la lista que un usuario no necesita ver de inmediato mientras la lista se vuelve a renderizar rápidamente durante el desplazamiento.

Y en su lugar, podemos mostrar skeletons. Para hacer esto, derivamos una posición de desplazamiento debounce de nuestro evento de desplazamiento y solo renderizamos las partes esenciales de nuestra nueva lista usando el valor en tiempo real. Para esto, una estrategia menos agresiva sería hacer esto solo en elementos en tus overflow buckers, aunque eso, por supuesto, viene con menores ahorros de rendimiento. Esto sí tiene un impacto en el usuario, sin embargo, así que recomendaría agotar todos los otros ajustes de rendimiento que puedas hacer detrás de escena antes de hacer esto.

A continuación, podemos imponer algunas restricciones menores a nuestros elementos de lista para acelerar significativamente la renderización en algunos casos. Pero primero, entendamos qué exactamente está sucediendo cuando un nuevo elemento se renderiza al desplazarse. La forma en que está configurado el 99% del tiempo es que el elemento que ha salido de nuestro viewport o overflow buckers se elimina del DOM y se crea uno nuevo en la dirección que pronto entrará en el viewport. Para el componente en el que inicialmente estaba implementando el desplazamiento virtual, encontramos que en realidad era mucho más lento crear y renderizar un nuevo árbol de elementos para un elemento de lista que volver a renderizar uno existente. Así que este patrón de crear y eliminar constantemente elementos estaba causando problemas de rendimiento al desplazarse.

Tus características de rendimiento podrían ser diferentes, pero hemos visto esto en una gama bastante amplia de casos de uso. Para mitigar esto, podemos usar una técnica que mi compañero de trabajo Justin Spedding ideó, así que bienvenidos a la parte de Justin de la charla. Lo que hacemos es crear un pool de elementos que se reutilizan al desplazarse. Para hacer esto, necesitamos calcular el número máximo de elementos que necesitamos, que es la suma de las alturas de los viewports y overflow buffers dividida por la altura mínima de cualquier elemento de lista. Este tamaño de pool podría hacerse dinámico, pero nuevamente, queremos evitar crear y destruir elementos si es posible aquí. Ahora podemos hacer un uso creativo de la propiedad key de nuestro framework para decirle que renderice nuestro pool de elementos de lista y simplemente cambie sus contenidos y comportamiento al desplazarse. En lugar de que la key sea el índice del elemento, es en su lugar el índice del elemento en el pool. Ahora el navegador solo enviará los contenidos de los elementos en lugar de tener que renderizar nuevos completos. Hacer esto proporciona una mejora del 35% en el rendimiento y benchmarks una lista del mundo real que usamos en Chatham.

También hay algunos casos donde esto puede ralentizarte, y lo abordaré en un segundo, pero props si puedes adivinarlo. Primero, sin embargo, esto pone algunas restricciones sobre lo que nuestros elementos hijos pueden hacer, así que cubramos eso. Con este enfoque, los componentes que componen tus elementos de lista tienen que ser funcionalmente puros. Es decir, que siempre producen lo mismo dados los mismos props y no tienen efectos secundarios. En términos de front-end, esto significa sin estado local, sin hooks de ciclo de vida, y sin estado global que no sea específico de los datos de los elementos de la lista. Esto no es un gran problema porque puedes envolver los elementos de la lista en su propio componente y hacer que se suscriban a una pieza de estado global que está particionada por pieza de datos en la lista en lugar de por componente. Puedes imitar un poco los eventos de ciclo de vida observando cambios en los props, pero si tienes un evento de ciclo de vida en un elemento de lista, entonces podrías querer echar un vistazo más amplio a tu arquitectura de todos modos. Además de esto, hay una técnica más que podemos usar para acelerar el rendimiento de la renderización. Puede que hayas notado que mientras compartir elementos proporciona una gran aceleración en el mundo real, técnicamente regresa nuestro rendimiento asintótico al desplazarse. Ahora estamos volviendo a renderizar tantos elementos como están en el viewport al cambiar los props de cada componente de elemento hacia arriba por uno al desplazarse en lugar de crear y eliminar un elemento. Así que si el viewport es demasiado grande, puede anular la aceleración de compartir e incluso causar regresiones en algunos benchmarks sintéticos. Así que construí una optimización adicional sobre esto para obtener lo mejor de ambos mundos.

Al desplazarse hacia abajo, en lugar de desplazar todos los props o contenidos del elemento hacia arriba uno y agregar uno nuevo en la parte inferior, tomamos el elemento superior y lo movemos a la parte inferior, luego cambiamos el contenido de ese elemento al del nuevo ítem, dejando todos los otros elementos igual. Esa es la descripción imperativa de ello. Declarativamente, podemos hacer un poco de matemáticas para representar esa transformación funcionalmente en JSX. En el código, estoy usando un flex box para hacer esto porque es más fácil de ajustar en una diapositiva, pero transformar los ítems individuales de la lista probablemente sea marginalmente mejor.

Básicamente, dividimos el pool de elementos en dos buckets, cada uno con el mismo tamaño que nuestro pool de elementos. El primer bucket contiene ítems antes del siguiente múltiplo de nuestro tamaño de pool, y el segundo bucket contiene aquellos después. Así que si nuestro tamaño de pool es 24, el primer bucket mostrará ítems del 0 al 23, y el segundo mostraría ítems del 24 al 47. El segundo bucket siempre se muestra después del primer bucket, independientemente de dónde esté en el DOM. Luego asignamos cada ítem de la lista al primer bucket para comenzar. Luego, cuando necesitamos mover el elemento a la parte inferior debido al desplazamiento, hacemos que muestre un ítem en el segundo bucket que corresponde al índice de ese elemento en el pool.

Así que cuando inicialmente nos desplazamos hacia abajo, el primer elemento en nuestro pool transiciona de mostrar un ítem en el primer bucket a uno en el segundo bucket, y por lo tanto mostrará el ítem 24 en lugar del ítem 0. Una vez que el ítem 24 sale del viewport, mostrará el ítem 48. Luego, una vez que todos los elementos están mostrando ítems en el segundo bucket, el segundo bucket se convierte en el primer bucket, y se forma un nuevo segundo bucket para los siguientes tantos ítems que el pool pueda contener. Ahora podemos ver nuestro pool de elementos siendo tratado como un buffer circular de algún tipo y solo re-renderizando un elemento a la vez al desplazarse. Esto lleva nuestro rendimiento de desplazamiento de vuelta a 01. Agregar esta optimización produce otra mejora del 30% en el rendimiento en nuestro ejemplo del mundo real y asegura que el rendimiento se mantenga consistente con viewports grandes, como en aquellos en monitores verticales.

Finalmente, quiero hablar sobre algunas de las limitaciones más amplias que vienen con el desplazamiento virtual y algunos nuevos estándares web que buscan solucionar algunos de estos problemas. El problema fundamental con el desplazamiento virtual que no se puede solucionar solo programando mejor es que no estamos renderizando todos los elementos, por lo que esos elementos no renderizados no aparecen en la búsqueda de control F o en el árbol de accesibilidad del navegador. Esto puede causar problemas para las personas que necesitan usar lectores de pantalla, por ejemplo, y significa que siempre necesitas implementar una barra de búsqueda para listas que quieras que sean buscables.

Hay una nueva propiedad CSS llamada content visibility que surgió de algunas charlas sobre cómo mejorar el desplazamiento virtual con estándares web. Cuando este prop se establece en auto, si el elemento no está en el viewport, seleccionado, enfocado o en la capa superior, el navegador omite renderizarlo por completo. Sin embargo, el elemento todavía está en el DOM y, a diferencia de display none, todavía está en el árbol de accesibilidad y puede ser seleccionado o enfocado. El navegador puede omitir renderizar el contenido, pero el contenido todavía está allí para control F y para lectores de pantalla. El problema, sin embargo, es que todavía tienes que construir un árbol DOM con todos estos elementos en tu carga inicial, lo cual en el mundo real, desafortunadamente, sigue siendo prohibitivamente lento. No he tenido mucho tiempo para experimentar con esto, pero dado lo que he visto, no veo que el desplazamiento virtual sea destronado por esto en el corto plazo.

Dicho esto, por lo que entiendo, content visibility no fue realmente diseñado para suplantar completamente el desplazamiento virtual, y es mucho más adecuado para páginas grandes con algunas secciones grandes que se renderizarán fuera del viewport en lugar de listas con muchos ítems pequeños. Para ese caso de uso, es la herramienta perfecta para el trabajo y recomiendo encarecidamente usarla. Así que, en conclusión, las listas son realmente comunes en el desarrollo web, y espero que esta charla te haya inspirado a sacar el máximo provecho de ellas. Hay mucho rendimiento que se deja sobre la mesa con el desplazamiento tradicional, y a menudo puedes llevar el desplazamiento virtual básico más allá también. El código de muestra para las técnicas discutidas en la charla estará disponible aquí. Así que, gracias por soportar mucho código en las diapositivas y mucho arte de programador, y por supuesto por ver mi charla. Y si hay tiempo para preguntas, estaré encantado de responder algunas.