Ahora, la forma típica de resolver esto es utilizando una técnica llamada debouncing. Básicamente, el debouncing significa que si un evento ocurre varias veces dentro de un cierto período de tiempo, digamos un segundo o medio segundo, entonces no lo activaremos. Esperaremos hasta que haya pasado al menos ese período de tiempo antes de activar el evento. Esto resuelve por completo el problema de que la aplicación se bloquee con datos grandes, porque puedo seguir escribiendo y nuestro círculo sigue girando alrededor del relojito y el área verde se mantiene pequeña. Pero si miras el gráfico detrás de él, no sucede nada. Nunca se actualizan. Solo cuando dejo de escribir, se actualizan. Y si hay muchos caracteres allí, muchos nodos, tiene sentido. Pero si solo hay unos pocos, verás que escribo un carácter ahora y tarda medio segundo antes de que los gráficos se actualicen. Y si sigo escribiendo lentamente, bueno, hay mucho tiempo para actualizar los componentes, pero sigo escribiendo dentro del período de debouncing. Entonces, en realidad, no se actualiza nada. Tenemos una aplicación receptiva, pero una que se actualiza lentamente. Incluso si no es necesario. Ahora, lo que aquí se llama asíncrono, lo llamaban modo asíncrono de división de tiempo en ese entonces, se llama modo concurrente en estos días. Como mencioné, el código subyacente actual probablemente sea muy diferente ahora, pero el principio de cómo funciona sigue siendo el mismo. Si comienzo a escribir y escribo lentamente, pero dentro de esos medio segundos, ahora veo que todo se actualiza y sigue actualizándose. Y no hay realmente una desaceleración y todo funciona bien. Pero si sigo escribiendo y entro en el área donde hay tantos nodos del DOM que no puede seguir el ritmo. Y ahora no se actualiza con cada pulsación de tecla, se actualiza cuando es posible, pero si no puede actualizarse dentro de algunos eventos clave, algunos eventos de pulsación de teclas, simplemente omitirá esa actualización. Entonces, mi aplicación responde lo más rápido posible y sigue siendo interactiva, que es exactamente lo que sucede aquí. Hace cosas y luego, si hay un evento, entra y permite que ese evento se active, y luego continúa. Si no puede terminar lo que hace, descartará algunas tareas y las encolará nuevamente para hacerlas más tarde, y esperemos hacer tanto como sea posible, mantenerlo lo más práctico posible. Ahora, en un navegador, hay un par de formas en las que podrías hacer esto. Pero resulta que hay una forma natural real para un navegador, porque un navegador tiende a actualizarse, al menos la mayoría de los navegadores lo hacen, a 60 cuadros por segundo. Entonces, 60 veces por segundo, el navegador intenta dibujar un cuadro en el DOM. Ahora, eso se reduce aproximadamente a 60 milisegundos entre cada cuadro. Entonces, si podemos dividir estos bloques de tal manera que estén dentro de los 60 milisegundos, es como si el usuario hiciera algo, puede suceder casi de inmediato y tenemos un límite realmente bueno. Y hay algunas API realmente buenas en el navegador, como requestAnimationFrame, y dentro de un cuadro de animación, puedes solicitar cuánto tiempo te queda dentro de ese cuadro de animación. Entonces, ese es el tipo de código que puedes usar para decir, bueno, comienzo a renderizar aquí. ¿Cuántos componentes puedo hacer? Bueno, si estoy aquí, todavía me quedan ocho milisegundos. De acuerdo, podemos hacer algunos más. Aquí me quedan cuatro milisegundos. Podemos hacer algunos más. Y luego, ¿dónde se fue mi mouse? Aquí, me queda un milisegundo. Ahora no nos queda suficiente tiempo para renderizar otro componente, así que vamos a pausar y comenzar el siguiente cuadro. Así que tenemos nuestras pausas y obtenemos todo el comportamiento interactivo. Como mencioné, estamos en Beta Land aquí. Ten cuidado de no usar esto en producción. Ahora, lo primero que debes tener en cuenta es este pequeño gráfico. Y esto siempre es un poco doloroso. Comienza aquí con el modo heredado, y luego está el modo de bloqueo y el modo concurrente. Lo que llaman modo heredado es en realidad la versión actual lanzada de React, pero llamarlo modo heredado suena sucio, ¿todavía estás usando el modo heredado? Bueno, no, eso es lo que se lanzó. No hay nada antiguo ni nada malo en ello. ¿Qué puedes hacer allí? Bueno, puedes usar referencias de cadena, puedes usar la versión antigua de contextos. Esto solo se aplica al contexto de estilo antiguo, no al nuevo. Eso seguirá funcionando. Puedes usar findDOMNode, otra API que no se usa mucho. Entonces, los primeros tres no se usan comúnmente. Y puedes usar suspense, que ya usamos. Ahora, para ser honesto, estábamos usando la versión de vista previa experimental de React, pero eso habría funcionado perfectamente bien con React normal. Todo lo demás detrás de esto, como las listas de suspense, los valores diferidos, el pre-renderizado interrumpible que describí, nada de eso funciona con el modo heredado. El renderizado es solo un gran bloque de ejecución, sin interrupciones, sin prioridades, nada de eso. Y sin lista de suspense. Hay un modo intermedio, lo que llaman modo de bloqueo. No es completamente concurrente, pero nos brinda algunas de las API como la lista de suspense. No estoy completamente seguro de por qué lo incluyen, porque es como, bueno, no es lo antiguo, pero tampoco es lo nuevo. Entonces, es como, bueno, está en el limbo, pero solo está disponible en la versión de vista previa de React, la versión experimental. Entonces, no puedes usar los modos de bloqueo en la versión actual tampoco. Si pudieras, tendría sentido adoptar algunas de las cosas nuevas, pero no, debes ejecutar la versión experimental. Y si lo haces, también podrías ir al modo concurrente completo. En realidad, nunca he hecho ninguna experimentación seria con los modos de bloqueo. Paso del modo heredado o el modo de producción real, como me gusta llamarlo, que suena mejor, al modo concurrente. Ahora, lo que pierdes son las referencias de cadena, el contexto heredado y find-dom-nodes, pero esas son API bastante antiguas que ya no son tan importantes. Y ganas todo un conjunto de cosas. Suspense, que podríamos usar de todos modos, pero ganas la lista de suspense, que mostrará y veremos la transición utilizada, y algunas otras cosas. Ahora, ¿cómo sabes si tu aplicación no está usando uno de esos primeros tres? Resulta que ya lo está comprobando. Entonces, si voy a index.tsx, ¿dónde está esta cosa, React.strictMode? Si ejecutas tu aplicación o parte de tu aplicación en React.strictMode, verifica si esos componentes no están haciendo nada mal. Esas características son inválidas, pero también cosas como actualizar el estado desde funciones de renderizado, etc. Entonces, para encontrar eso, en realidad duplicará la renderización de todos tus componentes en modo de desarrollo, no solo en modo de desarrollo, en modo de producción, esto no hace nada. Entonces, te ayuda a prepararte.
Comments