Adiós, useState

Hola, React Summit y adiós, ustedes estados. ¿Qué quiero decir con eso? Vamos directo al grano. Entonces, primero que nada, ¿quién soy yo? No importa. Acabas de escuchar, tenemos mucho de qué hablar.

Pero si realmente necesitas saber o acosarme en las redes sociales, soy David K. P. y estoy prácticamente en todas partes en línea. Creé la biblioteca Xstate, que es una biblioteca de máquinas de estados que si viste la primera charla, entonces la viste demostrada allí. Y hablando de estados, vivo en Florida, que es un camino de migración muy común desde Nueva York.

Sé que no estamos en Nueva York, estamos como en el estado equivocado, que también es el tema de mi charla. Pero de todos modos, también di una charla hace unos años llamada Goodbye Use Effects, muy similar a esta. Y en esa charla, expliqué muchas de las trampas de usar use effect, por qué es una especie de gancho defectuoso que es simplemente una pistola de pie realmente conveniente. Y por supuesto, como era de esperar, mucha gente estaba bastante enojada por esa charla diciendo que este tipo no sabe nada sobre React.

Use effect is super useful. Pero luego, ya sabes, cosas como esta suceden. Y sucedió de nuevo hoy, ¿OK? No lo planeé. No lo causé. Pero sí, Foul Player está caído de nuevo. Creo que todavía están caídos. No estoy seguro. Es por culpa de use effect. Pero el equipo de React en realidad sacó documentos diciendo que podría no necesitar un effect. Y estos documentos eran prácticamente mi charla Goodbye Use Effect. Así que podría hacer lo mismo para use effect que hice para use date porque, honestamente, necesitamos hablar de ello.

Sabes, esto no está realmente bien. Sabes, tenemos personas en línea diciendo, oye, sí, todo lo que tenemos que hacer es agregar otra use date porque ¿cuál es el gran problema con esto? Pero voy a intentar argumentar que no deberías hacer esto, y vamos a explorar algunos mejores patrones. Porque podrías estar pensando, oye, use date está bien. Agrego uno a mi aplicación. Es uno de los hooks más simples. No hay nada realmente malo con eso. Pero luego, ya sabes, agregas más, y se convierte en use 8, y luego las cosas simplemente se descontrolan. Y en ese punto, ya no estás codificando con vibra. Estás haciendo gestión de estado con vibra. Así que se convierte en un gran problema.

Pero, ya sabes, ¿cuál es exactamente el problema con use date? No es solo use date en aislamiento. Es cómo use date interactúa con todo lo demás en la lógica de tu aplicación, donde podrías tener un use date siendo usado en un use effect que necesita también actualizar otro use date. Y luego eso podría afectar las props en otro componente, lo que podría desencadenar un use effect allí, que llama a use date internamente en ese componente, lo que actualiza una prop, lo que llama a use effects en otro lugar. Así que simplemente se convierte en este gran, gran lío. Este es en realidad un ejemplo de algún código público real que he visto. Y quiero decir, solo mira este manejador. No estoy diciendo que esto sea malo. No estoy tratando de avergonzarlos. Esto es en realidad una pequeña startup.

Y entiendo que con pequeñas startups, como, realmente solo necesitas lanzar rápidamente. No tienes tiempo para pensar realmente en los mejores patrones ni nada. Solo tienes que hacer que algo funcione. Esta pequeña startup se llama Microsoft, por cierto. Y nos permite...

Pero ¿sabes qué? Puede que ni siquiera seas tú quien escriba el código de use date. Podría ser generado por Cursor o GitHub Copilot o uno de los logos de IA de butthole. Sabes, hay tres de ellos. Necesitas entender que los LLMs no fueron entrenados con buen código. Fueron entrenados con tu código. No tu código, sino solo el código de desarrolladores en general. Así que quiero reiterar que el problema no es...

Oh Dios mío. Hay tantos use dates en este componente. Es más que es difícil de entender cuando tienes muchos use dates y están siendo utilizados en muchas partes diferentes del componente, lo que hace que sea más difícil probar y corregir errores porque tienes que crear ese mapa mental de cómo todo está interactuando con cada uno, lo que a su vez hace que el código sea realmente difícil de mantener debido a toda esa corrección de errores y solo la carga mental de entenderlo. Y además de eso, incluso si todo eso estuviera bien, tienes problemas de rendimiento una vez que tienes más de un use date dentro de tu componente. Y explicaré eso en un minuto porque todo se vuelve a renderizar.

Y por supuesto tienes demasiado... Lo siento, no quise añadir eso ahí. No viste eso. Bien, hablemos primero sobre el uso excesivo de estados. Esto es algo que vemos mucho donde estamos usando estados para valores más primitivos como cadenas, números, booleanos y cosas así. Quiero decir que es absolutamente correcto e incluso recomendado agrupar datos relacionados. La forma en que usas date es un poco diferente una vez que haces esto. Y tienes que hacer algunos ajustes en los objetos para que las propiedades adecuadas funcionen, pero también hay soluciones para eso. Podrías, por ejemplo, usar emir, que si no has usado emir antes, es algo así como immutable JS sin toda la ceremonia elegante porque simplemente escribes tu código como si lo estuvieras mutando. Realmente no lo estás mutando. Parece que sí, pero sí, podrías actualizarlo directamente.

Así que cuando tengo datos anidados, que también es algo que deberías evitar, usa algo como emir o mutated, que es otra biblioteca para actualizar esos datos anidados. También controlar los re-renders. Así que como dije antes, el rendimiento se convierte en un problema con use date, especialmente cuando tienes muchos use date en los mismos componentes. Así que si has estado trabajando con React durante algún tiempo, puedes ver inmediatamente el problema con esto donde cualquier cambio en el valor va a causar que todo el árbol de componentes se vuelva a renderizar. Así que hay dos estrategias para eso. La primera es que podrías localizar fechas solo en los componentes que lo necesitan, o también podrías usar context.

Así que en este caso, tenemos un proveedor de valor y estamos usando context de valor en cada uno de estos componentes, se vuelve mucho más limpio. Ahora, sé que algunos de ustedes van a estar pensando esto, como, oye, esto es un problema. Mi proveedor. En realidad, argumentaré que no es un problema. Esto en realidad no es tan malo. De hecho, es una característica en Next.js para que puedan caber más triángulos dentro de tu aplicación. Pero, ya sabes, si realmente, realmente odias esto, hay una solución. Ve a la configuración de tu VS Code, establece el ancho de tabulación en cero, problema resuelto. ¿De acuerdo? No tienes que lidiar con eso. Otra cosa que puedes hacer es cuando tienes estados que realmente no necesitan volver a renderizar el componente, eso también es una indicación de que no deberías estar usando use date. Así que en este caso, estamos rastreando el número de veces que se hace clic en el botón, y este es en realidad un muy buen uso o un muy buen caso de uso para use ref donde podrías usar ref en su lugar y evitar pasar por ese ciclo de re-renderizado, porque esto no causará un re-renderizado. Así que solo recuerda, si los estados no necesitan causar un re-renderizado o no están involucrados en el renderizado, incluyendo pasar props, usa ref en su lugar. Así que use ref es para el estado interno, no relacionado con el renderizado.

Otro grande. Esto es cuando veo donde este patrón podría parecer bien, donde estamos controlando si una tabla está en orden ascendente o descendente. Pero el problema es cuando refrescas la página o cuando quieres compartir la página, todo ese estado se pierde. Y eso es en realidad una señal de que puedes usar estados de URL o estados de consulta. Así que Nuxt es en realidad una gran biblioteca para esto, donde en lugar de use state, usas estados de consulta como el valor predeterminado, y de repente, esto es en realidad parte de la URL. Y así es como un superpoder usar estados para parámetros de consulta de URL, recomiendo mucho esta biblioteca. Y también Nuxt y ShadCN son grandes bibliotecas con nombres raros, así que.

Sí, pero es, ya sabes, cada vez que ves una biblioteca con un nombre raro, pruébala, probablemente sea realmente buena. Aquí hay otro grande. Obtener datos. Bien, probablemente todos hemos visto este código antes. De hecho, te reto a que busques en tus bases de código de React y busques set loading o set is loading. Vas a ver un montón de estas cosas donde solo estás regurgitando estos mismos patrones una y otra vez. Y sé que algunos de ustedes podrían decir, obtener datos y usar use effect está bien, pero terminas con todos estos use states y tus componentes se vuelven realmente desordenados. Tenemos mejores patrones para esto en React 18, React 19.

Y finalmente, tenemos RSC, React Server Components, donde puedes simplemente esperar en los componentes y luego usarlo directamente en el JSX renderizado. Hay otro patrón que desearía que la gente usara más, que es use transition. Así que use transition en realidad facilita las solicitudes asíncronas y tener ese estado pendiente también. Así que en este caso, esto es casi directamente de los documentos. Estamos obteniendo el número de rebanadas guardadas de, ya sabes, esta función await update slices. Y luego comenzamos una transición para establecer las rebanadas nuevamente. Eso actualizará nuestros estados allí. Y ya tenemos nuestro estado pendiente, por lo que podríamos usarlo directamente en el componente. Esto se ve mucho más limpio que nuestro ejemplo de obtención dentro de un use effect. O puedes simplemente usar React, bueno, supongo que se llama Tanstaff query, porque honestamente va a manejar la obtención de datos y el almacenamiento en caché mejor de lo que lo harás para casos de uso más avanzados, e incluso para los básicos también. Los formularios son otro gran culpable también. Sabes, digamos que tendremos un formulario de biografía de usuario donde tenemos que agregar el nombre, algunas otras variables, establecer la biografía, etcétera. Y tenemos que incluir esto en los componentes, hacerlo controlado, agregarlo al valor. Y cuando cambia, necesitamos actualizar el estado. Todo es muy, muy manual.

Y luego estamos leyendo eso dentro de nuestra función. Y esto es un closure. Los closures también causan problemas si no tienes cuidado. Pero hay mejores patrones. De hecho, este está integrado directamente en el navegador. Se llama form data. Así que la idea es que realmente no necesitas hacer de esto un componente controlado. Solo le das un nombre. Y luego, en handle submit, todos esos datos están dentro de ese evento de formulario. Así que podrías simplemente leerlo desde new form data de ese events.target. Y si quieres hacerlo seguro en tipo y también en tiempo de ejecución, podrías analizarlo con Zod. Y podrías estar seguro de que los datos coinciden exactamente.

Así que este zero use date, lo hace realmente, realmente fácil. Y este es en realidad el patrón que Vercel recomienda mucho. Usan el hook use action state para actualizar ese estado, y podrías realmente leerlo dentro de una acción del servidor. Así que tenemos create user aquí. Tenemos los datos del formulario allí. Y eso es todo lo que necesitas hacer para conectar esos datos del formulario. Ahora, si hay algo más avanzado que necesitas hacer, entonces solo usa algo como tan stack form o react hook form o incluso final form de Eric Rasmussen, porque manejan formularios complejos mejor que tú, probablemente.

Otro, uniones discriminadas. Y esto suena como algo realmente malo políticamente, pero en realidad es realmente bueno en React. Volvamos a nuestro ejemplo de carga. Tenemos data, loading, error. Pero el problema es que estos son tres use dates separados. ¿Qué pasa si loading es true, pero también tenemos un error, pero también tenemos datos? Ahora, podrías decir, oye, eso nunca podría pasar en mi código. Pero no hay nada aquí que prevenga que eso suceda. Así que podríamos tener un estado imposible. Podríamos tener conflictos en nuestros estados. Así que una forma de mitigar eso es que podríamos tener un status como un enum de cadena en su lugar, así que en lugar de Booleanos, sabemos que solo podemos estar en uno de estos estados a la vez. Idle loading, success, o error.

Y luego podríamos usarlo aquí abajo y establecer el status. {{^}}Y luego podríamos renderizar basado en eso. Hay un pequeño problema con esto, sin embargo. Todavía no podemos garantizar si tenemos un error o si tenemos datos cuando es success. Así que lo que podríamos hacer en su lugar es crear esa unión discriminada. Y así esto combina el status y los datos o el resto del estado que está relacionado con ese status. Así que sabemos que cuando tenemos un error, va a haber una cadena de error. Y cuando estamos en el estado de success, definitivamente va a haber datos. Y así simplemente establecemos todo eso al mismo tiempo, lo que hace las cosas bastante convenientes. Así que ahora estamos reduciendo nuestros use states a solo una llamada. Y como resultado, tenemos estados perfectamente seguros en tipo.

Bien, pasando al siguiente, y sé que nos estamos moviendo rápido. Como dije, hay mucho de qué hablar. Estados derivados. Este es un gran error que veo incluso en desarrolladores senior. Así que tenemos nuestros estados centrales, nuestros estados esenciales. Por ejemplo, el número de donuts que hemos seleccionado. Digamos que estamos teniendo un formulario de pedido. Pero también tenemos estados derivados donde esta información puede derivarse realmente de nuestros estados esenciales, como el número total de artículos, subtotal, impuestos, etcétera, precio. Y luego típicamente ves esto, en un use effect, recalculando cada vez que uno de esos elementos cambia. Y solo hay un elemento en esta lista de dependencias, pero he visto listas de dependencias realmente largas donde están usando todo ese estado para derivar esos datos.

Entonces, ¿cuál es una solución aquí? Simplemente derivarlo directamente en Render. Así que esto debería ser conocimiento básico, pero te garantizo, mira en tus bases de código, ya seas junior o senior, vas a ver que tienes mucho estado que podría derivarse, y podrías deshacerte de muchos de esos use states. Sé lo que estás pensando ahora mismo. No esto, lo siento. Podrías estar pensando, odio los use states. Hay tanto en mi aplicación. Estoy aquí para hablarte sobre useReducer. Y probablemente estés pensando esto. Lo sé, lo sé.

Da la sensación de Redux 1.0, pero useReducer es realmente útil, porque antes teníamos estas funciones ad hoc, teníamos useState aquí, y podríamos en su lugar convertir esto en un reducer. Ahora, no voy a intentar convencerte mucho de useReducer. Solo voy a decir que al usar un reducer, centralizamos nuestra lógica, y eso hace que sea realmente fácil hacer cosas como separar esa lógica y escribir pruebas para ella. Y podrías pensar, no quiero escribir pruebas. Por eso uso una de las compañías con logo de butthole para hacerlo por ti. Y en mi opinión, usar la manipulación directa de estados lleva a una lógica ad hoc, porque esa lógica está dispersa por todas partes, y no tienes un lugar centralizado para ella. Pero al usar lógica basada en eventos, puedes centralizar esa lógica, lo que nuevamente, hace que sea más fácil para las pruebas, más fácil de entender, y cosas así.

También hay un hook realmente genial llamado useSyncExternalStore. Y esto es parte de la otra sección de hooks en React. Y no voy a hablar mucho sobre esto, porque probablemente no lo usarás en tu desarrollo de aplicaciones del día a día. Pero quiero mencionar que uno de los patrones más poderosos que podrías hacer es tener un store, solo una instancia de store, y pasar esos a componentes composables, en lugar de tener estos componentes Dios con una lista masiva de props para que manipules los internos y verifiques cuándo cambian las cosas. Un store funciona maravillosamente, y está evidenciado en bibliotecas como TipTap y otras bibliotecas relacionadas donde simplemente creas el store y lo pasas. Y todos esos probablemente están potenciados por useSyncExternalStore. Así que es algo para probar.

Los documentos de React te dirán, como, oye, tal vez deberías usar state y useReducer en su lugar. Dale una oportunidad, ¿de acuerdo? Pero eso me lleva a las bibliotecas de terceros. Entonces, ¿cómo llegamos a este punto? Porque algunas personas podrían decir, oh, solo necesitamos useState y useReducer. ¿Realmente necesitamos algo más? Por supuesto, si quieres state, usas state. Si ese state tiene lógica especial, ese es un gran caso de uso para useReducer. Si necesitas compartir eso entre componentes, entonces useContext, que es un hook desactualizado ahora, solo se usa ahora. Está causando demasiados re-renders. Así que podrías usar, como, un patrón de suscripción. Podrías no necesitar todo el state, así que ahora tienes que crear este useSelector personalizado para evitar demasiados re-renders. Ha aumentado mi alquiler. Usas Saran Lambdani. ¡Y felicidades! Acabas de reinventar Redux. Y Mark Erickson estaría realmente orgulloso de ti. Así que hay dos formas en que los stores típicamente se manifiestan en las aplicaciones cuando usas una biblioteca de terceros. Podrías importarlo directamente, o podrías compartirlo a través de context. Y hay muchas opciones para la gestión de estados.

Y por supuesto, ya que tengo el escenario, no voy a hablarte sobre XState, sino sobre XState Store. Porque XState Store es una biblioteca más pequeña. No te permite crear una máquina de estados completa, pero funciona igual que Zestand y Jotai combinados para permitirte proporcionar contexto, transiciones para cómo cambian los datos, y podrías suscribirte a ese estado o a esa store, podrías desencadenar eventos para enviar a la store para actualizar el estado, y puedes usarlo dentro de tus componentes también.

Así que en este caso, digamos que tenemos una app de pedidos de donuts, simplemente usas selector, lees de la store, y luego simplemente desencadenas acciones o desencadenas transiciones, tal como lo harías con cualquier otra cosa. Y así, con suerte, odias esto menos. Te recomiendo que lo pruebes. Podrías usarlo como una store global. Podrías usarlo como una store local. Y también puedes usar átomos. Así que podrías crear un átomo, configurarlo, podrías cambiarlo. Puedes tener átomos derivados donde se actualizarán automáticamente cuando los átomos que está leyendo se actualicen también. Y podrías suscribirte a eso. Y usarlos en React no puede ser más fácil. Usas atom, obtienes el valor, y luego configuras el átomo donde quieras.

Y así, esto es para el tipo más simple de store. Así que muy rápido, quiero hablarte un poco sobre el futuro de la gestión de estados. Y eso es con el estado local primero o motores de sincronización. Ahora, la idea es que en lugar de buscar datos manualmente de ida y vuelta entre tu base de datos, sincronizarás los datos en su lugar. Así que cada vez que tus datos locales se actualicen, actualizará la base de datos. Cada vez que tu base de datos se actualice, actualizará tus estados locales también. Funciona mágicamente. Y así es como funcionan cosas como Linear y Notion también. Hay muchas compañías detrás de esto. Y así que solo quería darte un adelanto de que cosas como esta, todavía están en días muy tempranos pero creo que esto va a ser el futuro. Y sí, así que deja que eso se asimile. Bien. Lo siento. De acuerdo. Así que usa estados.

Úsalo para componentes verdaderos, estado interno de la interfaz de usuario, porque no todo el estado es estado de la interfaz de usuario. Y pregúntate, ¿hay un mejor patrón? Porque usualmente lo hay, especialmente con React 19. Y por supuesto, también hay documentación. Uno de los documentos más importantes que siento que deberías leer es elegir la estructura del estado porque recorre todas estas estrategias, agrupando estados relacionados, evitando contradicciones y estado redundante, evitando duplicación en estados, de lo cual hablamos con el estado derivado, y evitando también el estado profundamente anidado. Así que por favor haz de esto una lectura obligatoria. Así que comienza con el estado usado, refactoriza a mejores patrones y enfócate en el mantenimiento, porque simple es mejor que fácil. Y con eso, muchas gracias, React Summit.

Muy bien. De acuerdo. Así que tenemos una pregunta de Andrew aquí. Él está preguntando, ¿es use memo una buena solución alternativa para manejar el estado derivado y asegurar que no se recalcule en cada renderizado? Yo diría que usa use memo solo cuando lo necesites, porque lo que ahorras en costo de computación, lo incurres en costo de memoria con use memo. Así que si tienes demasiados use memos, podría causar problemas. Es una de esas cosas donde sabrás cuándo lo necesitas. Es como, wow, esto es lento. Esto está causando muchos cálculos. Así que entonces usa use memo. Y también el compilador de React, creo que ahora si lo usas, está disponible ahora mismo, creo. Pero puedes usar eso en lugar de use memo, porque hará todo automáticamente. Sí, esa es una buena pregunta, Andrew.

La siguiente, tenemos a Kyle de Nextdoor. ¿Existen linters para ayudar a fomentar mejores prácticas alrededor del uso del estado? Creo que sí, no en la medida en que hablé en esta charla, pero porque a veces es difícil decir, como, hey, este estado es derivado, pero no es inmediatamente obvio al recorrer el AST o algo así. Pero esa es una buena idea. Podría escribir uno. Oh, inspirador. Parece que se perdió la conexión, pero lo tengo. OK, y este es de JD Collins. En 2025, ¿todavía hay lugar para Redux? Por supuesto, sí, especialmente con Redux toolkit. Si todavía estás pensando en el viejo Redux, ya sabes, con tu despachador de acciones, etc., por favor, por favor, dale una oportunidad a Redux toolkit. Honestamente, solo es similar por nombre y por filosofía, pero es una API muy diferente.

Diría que no puedes equivocarte eligiendo una solución de gestión de estado que te ayude a centralizar la lógica de tu aplicación, y Redux toolkit lo hace bien, al igual que Dustin, Xstate y Xstate Store intentan hacerlo lo mejor que puedo. Así que, sí. Entonces, sí en 2025, ¿y piensas en los próximos años? Sí, lo creo, porque echa un vistazo a una base de código de React que no tiene ninguna gestión de estado centralizada. Si se ve bien y funciona bien, entonces la gestión de estado probablemente sea realmente simple también. No todas las aplicaciones tienen ese nivel de complejidad simple. Así que, cuando las cosas se vuelven más complejas, la gestión centralizada del estado, lo que decidas usar es el camino a seguir. Simplemente no intentes crear la tuya propia. Al menos, usa Reducer en contexto. Suena bien. Entonces, la respuesta es mantenerlo.

OK, de Katie, ¿hay una diferencia entre Adams y Ustate? Sí. Entonces, con Adams, que fue popularizado por Solid y luego Recoil, luego Jotai también tiene Adams. La idea es que son pequeñas piezas de estado donde las actualizas y deberían causar actualizaciones. Así que, son reactivos. Así que, cualquier Adam que esté leyendo ese Adam, ese Adam también se actualizará debido a ese Adam. Así que, es más para gestión de datos granular, lo llamaría más gestión de datos que gestión de estado porque estás actualizando pequeñas piezas de datos, y es mucho más simple que tener una tienda completa o una máquina de estados. Así que es un poco diferente de Ustate, sí. Sí. Oh, está arriba.

Genial. ¿Hay una hoja de referencia disponible en algún lugar que ayude a referenciar todas estas alternativas a Ustate que acabas de presentar? Hay dos cosas. Están los documentos de React, especialmente los que enlacé en una de las últimas diapositivas que eligen la estructura del estado. Y está lo opuesto a una hoja de referencia donde es una masterclass de cinco horas que di en Frontend Masters. Si tienes una suscripción, entonces lo enseño allí también. Genial. Bueno, escribiré una publicación de blog o algo que lo resuma todo. ¿Estás seguro de que simplemente no quieres que la gente te escuche hablar durante cinco horas? No, no puedo hablar durante cinco horas. Nadie quiere eso. Oh, espera, tenemos un impostor aquí.

La mejor Daphne. No pregunté eso, pero seguro. ¿Eso implica que alguien más piensa... Está bien. ¿Cómo animas a tus equipos a evitar Ustate y los bucles de efecto? Quiero decir, eso depende realmente de tu equipo. Puedes hacerlo en la etapa de revisión de código o simplemente mostrar mejores patrones. Diría que hoy en día, una de las cosas que realmente no nos gustaba de UseReducer es simplemente cuántos boilerplates y cuánto teníamos que escribir las acciones y despachar eventos y todo eso. Pero con la codificación asistida por IA, solo tocas, tocas, tocas, y lo hará todo por ti. Y los asistentes de codificación de IA aman el código explícito donde todo el texto está justo ahí. Así que, honestamente, pruébalo. UseReducer es más fácil de escribir ahora que nunca. Sí, asistido por IA. No puedo mirar los logos de la misma manera. Lo siento. Lo vi en algún lugar. Estoy como, ¿sabes qué? Eso sí parece una parte del cuerpo. Sí.

Lo es. ¿Cómo manejarías el estado de validación de formularios de nd? Cuando llegas a la validación de formularios, hay un par de cosas que podrías hacer. Podrías usar la API de validación HTML5 incorporada. Pero si obtienes algo más complejo que eso, es cuando la gente argumentaría, oh, necesito usar estado, etc. Es cuando realmente iría a una de las bibliotecas de gestión de formularios, como Final Form, TanStack Form, o React, el Hooks Form. Sí. Tiene sentido. Esta es de Mark. ¿Por qué los patrones de actualización basados en eventos son más mantenibles a largo plazo? Realmente depende. Si tienes estados muy simples, entonces podría no serlo, porque es como, está bien, solo necesito actualizar. No necesito esta indirecta. Pero la razón principal por la que lo son es que te permite centralizar tu lógica para que en lugar de tener un manejador que llame a 20 estados de uso, es como, imagina si olvidaste uno de esos o si otro desarrollador en otro equipo decidió llamar directamente al estado de uso en algo donde estás como, oh, no, no se supone que debes llamar directamente al estado de uso allí.

Te ayuda a centralizar tu lógica y tenerla toda en un solo lugar, lo cual es bueno para entender, porque solo tienes un archivo para leer. Y también es bueno para las pruebas, lo cual creo que es extremadamente importante. Deberías poder probar tu lógica de forma aislada. Sí, eso suena súper útil.

¿Cuál es tu motor de sincronización favorito para probar de Kiran? En realidad, no lo llamaría un motor de sincronización directamente. He estado usando Convex. También recomendaría LiveStore de Johannes Schickling. Sí, he oído hablar de Convex. Genial.

De Spence, ¿cuáles son tus pensamientos sobre usar 10-Stack Query Global Cache para una solución de gestión de estado global? Aún no lo he usado. No le digas a Tanner que está en la otra habitación, así que no me escuchará. Pero confío en todo lo que Tanner hace en todo 10-Stack, así que definitivamente recomendaría probar sus cosas. Suena bien. El secreto se queda en esta habitación. Y de Brendan, ¿cuáles son tus pensamientos sobre los eventos de use effect? ¿Crees que eso hará que la relación entre use state y use effect sea más estable? Los eventos de use effect son como uno de esos hooks requeridos ahora, porque creo que mucha gente todavía está usando use callback y teniendo ese enorme array de dependencias. Así que los eventos de use effect te permiten realmente evitar ese feo array de dependencias. Evita el problema de cierre obsoleto, y es algo que definitivamente deberías usar más a menudo. Increíble. Muy bien. Eso es todo el tiempo que tenemos para preguntas. Un aplauso más para David. Gracias.