Entonces, para ampliar un poco, ¿qué estamos realmente viendo aquí? Bueno, realmente lo que estamos diciendo aquí es que para la estructuración inicial de propiedades, creamos una nueva vinculación, pero esto es, por supuesto, reactivo, esta prop puede cambiar entre renders, y eso es lo que dice este HDR actual. Luego cargamos usuarios 22 en esta nueva variable temporal 24, esto también es reactivo, porque estamos leyendo la variable reactiva usuarios 22, por lo que el valor de esta cosa atómica específica en nuestra función puede cambiar entre renders. Ahora, acceder al método filter aquí también puede cambiar entre renders, porque si estamos trabajando con un nuevo array de usuarios, y los arrays son objetos, lo que significa un objeto completamente nuevo, este método filter estaría en un objeto completamente nuevo, por lo que esto también puede cambiar entre renders. Así que nuevamente, esta fase asegura que cada valor que podría cambiar entre renders se marque como reactivo. Y estos valores reactivos son exactamente lo que el compilador quiere optimizar. No tiene sentido memorizar algo que nunca cambia, pero los valores que pueden cambiar entre renders son perfectos para el almacenamiento en caché. Así que ahora el compilador conoce tanto el comportamiento de las operaciones a partir de los efectos, como también qué valores realmente importan para el renderizado reactivo para el análisis reactivo.
Bien, así que en este punto, tenemos nuestro código desglosado en un HDR, tipos, efectos, y así sucesivamente, y también sabemos qué valores pueden cambiar entre renders. Ahora el compilador tiene que decidir qué operaciones deben almacenarse en caché juntas, y cuáles deben ejecutarse cada vez. Las variables que cambian juntas también deben almacenarse en caché juntas. Así que ahora es el momento de la siguiente fase que es el descubrimiento de ámbitos. Así que ahora el compilador tiene que decidir qué operaciones deben almacenarse en caché juntas, pero la idea es que las variables que cambian juntas deben almacenarse en caché juntas, y las variables que cambian independientemente deben almacenarse en caché independientemente. Así que durante esta fase, el compilador agrupa la operación en función de sus dependencias, por lo que las operaciones que dependen de las mismas entradas se agrupan en el mismo ámbito. Así que después del descubrimiento de ámbitos, nuestro HDR ahora se ve algo así donde tenemos tres ámbitos. Primero, tenemos el ámbito cero que son solo las funciones de callback porque las funciones obtienen su propio ámbito porque pueden memorizarse independientemente porque no dependen de ningún valor reactivo, por lo que esto puede almacenarse en caché una vez y luego reutilizarse en todos los renders prácticamente. Ahora el ámbito uno cubre las instrucciones tres, cinco y seis, y todas dependen de la entrada del usuario para estas operaciones de filtrado. Todas necesitan recalcularse cada vez que el array de usuarios cambia, por lo que todas se agrupan.
Así que ampliando, toda esta operación de filtrado ahora se convierte en su propio ámbito memorizable. Esto es casi como lo que teníamos con useMemo, pero ahora se hace automáticamente por el compilador. Y el callback de filters también se extrae completamente porque esto no depende de nada y esto podría simplemente reutilizarse en todos los renders. Incluso obtenemos un ámbito separado para la creación de JSX, por lo que esto solo se recalcula cada vez que count cambia. Así que si el array de usuarios cambia pero la cantidad total de usuarios es la misma, entonces podemos simplemente reutilizar este JSX almacenado en caché, y esto es algo que es prácticamente imposible de hacer con useMemo pero se hace automáticamente con el compilador. Después de obtener su propio ámbito, la función de callback ahora se convierte en una función separada. Así que la lógica sigue siendo exactamente la misma pero es solo su propio bloque, y esto es genial porque no tenemos que crear un nuevo objeto de función ahora en cada render. Así que el compilador identifica automáticamente estas como funciones puras y las extrae lo que es un mejor rendimiento que veremos en el resultado final también. Así que en este punto los ámbitos simplemente existen como anotaciones en nuestro HDR pero necesitan convertirse en fuentes de flujo de control reales para la generación de código. Así que el compilador ahora estructura el ámbito en una presentación diferente que muestra claramente qué instrucciones pertenecen a cada ámbito y también cuáles son sus dependencias y salidas. Así que ahora puedes ver claramente que el ámbito uno depende de la variable de usuarios y produce el resultado del filtro mientras que el ámbito dos depende de count y produce este JSX. Así que este flujo de control explícito ahora es muy importante para la siguiente fase, finalmente llegamos a la generación de código. Así que esto convierte nuestro HDR en el JavaScript optimizado que vimos desde el principio.
Comments