Entonces, estas deficiencias significaron para nosotros que realmente necesitábamos construir nuestra propia versión en Shopify y la llamamos FlashList. Los objetivos de los proyectos han sido lograr una alta tasa de fotogramas tanto para UI como para JSFPS. Queríamos minimizar tanto como fuera posible la visualización de elementos vacíos y queríamos hacer que la biblioteca fuera realmente fácil de usar y lograr tanto rendimiento como pudiéramos para una experiencia de desarrollador realmente fluida.
Entonces, esta es la API para FlashList que hemos ideado y como puedes notar, hemos cambiado principalmente el nombre del componente de FlatList a FlashList y tratamos de mantener la gran mayoría de las props iguales. Ahora, hay algunas props en FlashList que no existen en FlatList para lograr un mejor rendimiento, y aprenderás sobre algunas de ellas más adelante en la masterclass. Las alturas dinámicas no suponen ningún problema y, como mencioné, eso es incluso con el tipo de API de FlatList. Entonces, permíteme responder a una pregunta ahora, ¿cómo es FlashList tan rápido? Y comenzaré explicando cómo funciona FlatList primero. Entonces, en FlatList, tenemos un par de elementos que están en el viewport aquí, índices del cuatro al seis, luego tenemos un par de elementos precargados que están en la parte inferior de la lista. Y luego tenemos un par de elementos que todavía están cargados en memoria, dos a tres. Ahora, la cantidad de elementos en memoria en el caso de FlatList es bastante alta. Pero a medida que te desplazas hacia abajo lo suficiente, FlatList necesitará liberar algo de espacio en la memoria. Y ahí es cuando entra en juego el componente VirtualizedList que FlatList usa debajo del capó. Y lo que hará es que a medida que te desplazas hacia abajo, vaciará los elementos, de modo que reemplaza el contenido con solo una vista vacía y mantiene las dimensiones de la celda, por lo que el diseño de la lista no cambia. Esto también significa que a medida que te desplazas hacia arriba y llegas a estos elementos vaciados, siempre tendrás que renderizarlos desde cero. Y también a medida que te desplazas hacia abajo y necesitas cargar más elementos, también siempre tendrás que renderizar estos elementos desde cero, lo que consume muchos recursos. Como visualización, aquí puedes ver celdas con sus ID de instancia. Y a medida que nos desplazamos hacia abajo, simplemente obtenemos más y más ID, lo que significa que podemos obtener más y más instancias. Y de nuevo, todo necesita ser renderizado desde cero. Entonces, para resumir, Flando usa esta lista virtualizada debajo del capó. Y a medida que te desplazas, reemplaza las celdas con contenido vacío. Y lo importante a tener en cuenta es que las celdas siempre se renderizan desde cero, a menos que estén en memoria, lo que consume, de nuevo, muchos recursos. Las plataformas, por otro lado, adoptan un enfoque diferente. Nuevamente, tenemos un par de elementos en el viewport. Tenemos algunos elementos que están precargados, pero la cantidad de esos elementos es bastante baja. Y lo más importante, tenemos un concepto llamado Recycling Pool. Entonces, a medida que nos desplazamos por la lista, los elementos que ya no son visibles en la pantalla, se colocan en el Recycling Pool. Y luego, cuando necesitamos cargar más elementos, FlashList mirará en el Recycling Pool, y si hay algún elemento que actualmente no está en uso, moverá ese elemento de vuelta a la lista y simplemente lo volverá a renderizar con los nuevos datos. Esto significa que, por ejemplo, si solo cambia un texto en la celda, tendrá que volver a renderizar solo esa parte, y no tendrá que crear nada desde cero. Y eso lo hace bastante eficiente. Como visualización, puedes ver cómo a medida que nos desplazamos, los elementos se van colocando en el recycling pool, y luego, cuando necesitamos crear más elementos en la parte inferior de la lista, FlashList comenzará a sacar los elementos del recycling pool de vuelta a la lista, y comenzaremos a obtener instancias e ID que hemos visto antes. Y de nuevo, esto ahorra muchos recursos. También necesitábamos solucionar el problema del primer diseño de renderizado. Entonces, así es como se veía el problema del primer diseño con Recycle List View, y puedes ver que los elementos se superponen entre sí. Ahora esto es solo por un par de fotogramas, por lo que esta grabación se ralentiza para hacer esto más obvio. Para profundizar en el problema, en el lado izquierdo, tienes cómo Recycle List View espera que se vea el diseño. Espera que cada elemento sea el mismo dependiendo también del tamaño estimado del elemento, que es un problema del que también aprenderemos más adelante en la masterclass. Pero el diseño real, lo que realmente se renderiza en la pantalla, es diferente. Aquí tenemos el elemento número cero que tiene, por ejemplo, 100 píxeles de altura, pero luego el elemento número uno, tiene, por ejemplo, 200 píxeles, pero Recycle List View todavía cuenta con que solo tiene 100. Y entonces el elemento número dos está entonces sobre el elemento número uno, lo que resulta en elementos que se superponen entre sí. Entonces, implementamos una vista nativa llamada Auto Layout View que recorre toda la lista. Y cada vez que ve elementos que se superponen entre sí, o cuando hay espacios entre elementos, automáticamente soluciona esos problemas de UI y coloca todo de borde a borde como se supone que debe ser. Entonces, con FlashList, si miramos la grabación, podemos saber cómo. Para resumir la implementación de FlashList, tenemos una API que es muy similar a FlatList. Hemos implementado una vista nativa para solucionar el problema del primer renderizado. Hemos podido lograr una altura de celda dinámica de alto rendimiento con la API simple similar a FlatList y hemos utilizado Recycle como el motor interno en el que hemos construido para lograr la API.
Comments