Type-Safe URL State Management in React With nuqs

Hola a todos. Mi nombre es François Best. Soy un ingeniero de software freelance de Grenoble en los Alpes franceses. Y hoy quiero hablarles sobre esta biblioteca que hice llamada nuqs. Es utilizada por empresas de todo el mundo como Sentry, Superbase, Vercel, Clerk, y muchas más. Y es un gestor de estado de parámetros de búsqueda con seguridad de tipos para React. Su objetivo es hacer que los estados de URL sean agradables en React, en todo React, todos esos tipos soportados.

¿Qué es exactamente el estado de URL? Es la idea de almacenar parte del estado de nuestra aplicación en los parámetros de búsqueda o cadena de consulta, esa tienda de clave-valor después de la parte del signo de interrogación de la URL. ¿Por qué querrías hacer esto? Hay una razón incorrecta. Si lo que quieres lograr es no perder las actualizaciones de estado que hiciste cuando recargas la página, esa no es una razón suficiente por sí sola para ponerlo en la URL. Porque la resiliencia al recargar es más un efecto secundario, y puedes lograrlo con otros medios como el almacenamiento local, por ejemplo.

La verdadera razón por la que quieres poner estados en la URL es que le da a tus aplicaciones dos superpoderes. El primero es la teletransportación. Al compartir un enlace con otra persona, teletransportas la representación en memoria de ese estado desde tu navegador al de ellos, para que puedan ver lo mismo que tú, continuar donde tú lo dejaste. Esto es también algo que llamamos deep linking. El segundo superpoder es el viaje en el tiempo. Un marcador es una forma de enviar un enlace hacia adelante en el tiempo a tu yo futuro. El historial de tu navegador es una forma de viajar atrás en el tiempo, para recordar estados del pasado. Si usas el botón de retroceso del navegador para depurar tu estado como un deshacer-rehacer, solo ten en cuenta que podrías romper el botón de retroceso. Ten en cuenta eso.

Entonces, ¿cómo funciona en la práctica? Si vemos la URL como el límite entre el cliente y el servidor, se convierte en este lugar natural para que intercambien datos entre sí. El cliente puede adjuntar algunos estados en la solicitud del documento en el que está, el servidor lo recoge, lo usa para la obtención de datos, filtrado, renderizado de contenido personalizado. Nada nuevo sobre esta parte. Así es como la web ha estado funcionando siempre. La principal diferencia es que ahora tenemos un cliente que puede reaccionar a los cambios en la URL, y así el servidor también puede responder usando el mismo sistema. Con un redireccionamiento, puede pasar algún estado de vuelta al cliente para que lo maneje del lado del cliente. Así que tenemos este enlace de comunicación bidireccional entre el cliente y el servidor usando solo el texto de la URL, lo cual es bastante poderoso. Ahora, hay algunas advertencias a este enfoque, y creo que como buenos ingenieros es importante que conozcamos las limitaciones de los sistemas con los que estamos trabajando. Así que pasaré por cinco problemas diferentes que puedes encontrar con el estado de la URL. El primero es que la URL tiene un límite de tamaño.

La limitación práctica no va a ser técnica, será social. Es la de nosotros los humanos, porque no nos gustan los enlaces largos. Por ejemplo, entre estos dos enlaces, que son semánticamente equivalentes, ambos representan un estado de tabla de 10 pilas, ¿en cuál preferirías hacer clic? El segundo, exactamente. Porque primero, parece menos intimidante, es más pequeño, por lo que se ajusta a nuestros criterios. Pero también puedes entender lo que va a hacer solo con leerlo. Es una interfaz de usuario. Es la primera interfaz de usuario que tus usuarios verán antes de llegar a tu aplicación. Así que quieres diseñar tus enlaces al menos tan bien como tus imágenes de open graph.

El segundo problema que podríamos tener con esto es que una vez que los usuarios han compartido enlaces por internet, están fuera de tu control. Y si quieres introducir cambios importantes en los programas de búsqueda que aceptas en tu página, ahora tendrás que ejecutar migraciones contra esas URLs que llegan. Porque no quieres romper los enlaces existentes. Las URLs geniales no cambian, quieres respetar la semántica de los enlaces que se han compartido en el pasado tanto como puedas. Y así, esto se puede hacer con middleware de migraciones y redirecciones para devolver a tu aplicación el resultado de la URL migrada.

Otro problema que no es muy conocido es que los navegadores limitan la tasa de actualizaciones de URL cuando las actualizas del lado del cliente, por razones de seguridad. Y nuqs resuelve esto con una característica que me gusta llamar seguridad temporal, que es el desacoplamiento de la UI. Así que tienes actualizaciones de estado local optimistas instantáneas para métricas como AMP y mantener tu aplicación receptiva. Y por otro lado, limitando las actualizaciones de URL a una tasa que el navegador pueda manejar. Notas que en realidad no tienen la misma tasa. Así que necesita adaptarse a esto. Y además de esto, puedes agregar algunas semánticas de debounce en caso de que solo estés interesado en el estado final para actualizaciones de alta frecuencia como entradas de texto o un deslizador, por ejemplo. Otro problema que puedes encontrar es que al poner el estado en la URL, creas puntos de entrada en tu aplicación.

Y así, la máquina de estados de tu frontend ahora tiene que ser consciente de estos atajos a través de los cuales literalmente puedes entrar. Porque la gente no solo navega haciendo clic en toda tu aplicación. Así que necesitas ser consciente de estas cosas. Y el punto final es el SEO. TLDR, quieres definir una representación canónica para cada página donde tengas parámetros de búsqueda para que los rastreadores de motores de búsqueda puedan indexar lo correcto. Y puedes tener parámetros de búsqueda allí, como la página de visualización de YouTube, por ejemplo, tiene el ID del video en el parámetro vsearch.

Muy bien. Así que ahora que hemos visto algunos problemas, echemos un vistazo a algunas soluciones. ¿Cómo funciona nuqs? Bueno, hagamos una demostración. Así que, aquí tengo el hola mundo de la gestión de estado en React. El botón contador. Todos hemos visto esto. Hago clic en este conteo. Se incrementa. Pero ese estado está bloqueado en el espacio y el tiempo en esta pestaña del navegador. ¿Cómo lo sacamos a la URL para hacerlo compartible? Vamos a reemplazar use state con use query state de nuqs. Y el primer argumento no va a ser un número. Va a ser el nombre de la clave que quiero en la URL. Count.

Y si guardo esto, notarás que mi estado ha desaparecido. Mi tipo de dato ahora es string o null. Es null si no hay nada en la URL. Y por defecto, todo es una string. Así que necesitamos decirle a nuqs que estamos trabajando con un número aquí. Hacemos eso con un parser. Parse as integer. Y así ahora mi tipo de estado es number o null. La otra cosa a notar es que es compatible con la API de use state. Tenemos el valor que está en la URL y una función para actualizarlo. Este null, sin embargo, es molesto porque está rompiendo nuestra lógica aquí.

Así que podemos hacerlo no anulable pasando un valor por defecto con default zero que será devuelto cuando no haya nada en la URL. Y ahora hemos mantenido nuestro botón. Y funciona de nuevo. Puedo incrementarlo, copiarlo, enviarlo a un amigo o a otra pestaña. Y he teletransportado mi estado de una pestaña a otra. Simple.

¿Cómo funciona esto? Porque este componente realmente funcionaría en cualquier framework de React. Entonces, ¿cómo funciona? Aquí estoy en el enrutador de la aplicación nuqs.js. Así que si voy a mi archivo de diseño, archivo de diseño raíz, verás que tengo este proveedor de nuqs adapter aquí que importo directamente del enrutador de la aplicación nuqs.js especificado para ello. Y le dice a nuqs cómo funciona mi framework, cómo leer la URL usando useSearch params en este caso, y cómo actualizarla.

Y cómo actualizarla es ahora por qué necesitamos mirar la pestaña de red. Verás que si hago clic en el botón, la URL se incrementa, pero no se realiza ninguna solicitud de red. ¿Y por qué es eso? Bueno, si volvemos a nuestros componentes, notamos que este es un componente cliente que existía en useState en memoria justo aquí antes. Y esta es una página estática. Así que no estamos escuchando los parámetros de búsqueda en el servidor. No hay razón para ir a través de la red para esto. Pero aún así, necesitamos entender las dos formas de actualizar la URL.

Nuestros enrutadores generalmente nos proporcionan una API desde useRouter, usesLatNavigation, useHistory, cosas así. Y eso generalmente enviará una solicitud de red para realizar la renderización del lado del servidor utilizando esos parámetros de búsqueda en el servidor. Pero hay otro método, la API de History, que está integrada en el navegador. No es algo de Next.js o de ningún framework. Y esto solo actualiza la URL del lado del cliente. Esto es algo que también llamamos enrutamiento superficial. Y nuqs usa esto por defecto, porque estamos seguros de tener un cliente donde ejecutamos esos hooks. No estamos necesariamente seguros de tener un proceso de renderización del lado del servidor en el otro lado.

Entonces, ¿qué sucede si queremos cruzar la red para hacer renderización del lado del servidor? Así que echemos un vistazo a otra demostración. Bien. Cierra esto. Aquí, tengo una lista de álbumes con algunos filtros que puedo mostrarte el código. Esto es un... No este. Página. Esta es una página de componente del servidor en Next.js que obtiene los datos de una base de datos, renderiza estos filtros, y luego la cuadrícula de álbumes. Y así, queremos crear una interfaz de usuario compartible para esto. Así que vamos a empezar a declarar lo que necesitamos.

nuqs utiliza un enfoque declarativo. Así que voy a crear un nuevo archivo junto a mi página llamado searchparams.ts. Y aquí, voy a describir lo que necesito en un objeto. Así que, searchparams. Las claves en este objeto van a ser las claves en la URL. Así que, tendré query. Y los valores van a ser los analizadores para los tipos que necesito. Así que, parse as string. Voy a importarlo desde nuqs server.

Eso es algo específico de Next.js solo para propósitos de directivas de uso del cliente. Definiré un valor predeterminado de cadena vacía. ¿Por qué no? Y liberar. Sí. Analizar como entero. Y no vamos a definir un valor predeterminado para este porque realmente no tiene sentido.

Lo que tengo ahora es un objeto descriptor que puedo reutilizar en toda mi aplicación. Hay dos lugares donde lo necesitaré. En el servidor para analizar del lado del servidor, la solicitud que llega, y en el cliente para conectar a mi interfaz de usuario.

Así que, comencemos con el servidor. Vamos a definir lo que llamamos una función de carga en nuqs. Const load filters equals create loader. Y voy a pasarle este objeto descriptor de parámetros de búsqueda. Y esta función la puedo llamar con muchos tipos diferentes de entradas. Aquí estoy usando Next.js, pero podría pasarle la solicitud en un cargador de remix o React router, por ejemplo.

Const filters equals load filters. Pásalo los search params. Ahora, este search params prop es una promesa. Así que, necesito await aquí. También puedo await el resultado. Si pasas una promesa a un loader, te da una promesa a los valores analizados. Y puedo pasar esto a mi base de datos.

Y si miramos el tipo de datos, vemos que coincide con el esquema que definimos antes. Aún no tengo una interfaz de usuario para esto, pero ya puedo usar la barra de URL como entrada. Así que, si hago query Beatles, tengo todos los álbumes de los Beatles. Genial. Bien, conectemos nuestros filtros ahora. Estos son nuestros componentes del cliente. Necesitamos envolverlo en suspense.

Pero lo que vamos a hacer es que necesitaremos un hook allí. Así que, vamos a exportar un hook desde nuestro archivo de definición de search params. Vamos a hacer exports const use filters. Y vamos a reenviar esto a use query states con una S esta vez, que trata con search params descriptor objects. Y esto ahora lo puedo usar en mi componente de filtros.

Entonces, misma API que el valor de estado y una función para cambiarlo, use filters. Los valores serán un objeto con estas dos propiedades. Y la función de estado de datos será set search params. Ahora, cuando descomente estos, React se quejará de que estoy pasando de no controlado a controlado. Pero mira lo que sucede en la entrada cuando guardo. Guarda este. Ves que recogió el estado de la URL porque la URL es la fuente de verdad. Pero ahora, si recuerdas lo que dije sobre el botón, notarás que si escribo algo aquí, no pasa nada.

¿Por qué es eso? Porque todavía estamos en este modo superficial, solo modo cliente. Y necesitamos decirle a nuqs que queremos cruzar la red. Y así lo hacemos con una opción que puedo definir aquí. Así que está co-localizado con el resto de mi hook llamado shallow false. Así que cuando guardo esto, recoge esa cosa, la envía a través de la red al servidor. Y obviamente no hace nada, pero puedo hacer beetles y 1967 beetles para sergeant Peppers. Genial.

Así que conectemos nuestro botón de limpiar, marcar botón de limpiar. Podemos hacerlo así. Podríamos establecer parámetros de búsqueda individuales al valor predeterminado. Pero recuerda lo que dije sobre no, no significa no en la URL. También significa limpiar de la URL cuando escribes. Así que podemos hacer esta pequeña abreviatura de establecerlo en no. Y una cosa interesante es lo que sucede si tengo algo no relacionado en la URL, como foo equals bar en el medio. Y hago clic en limpiar. Mantiene el resto de la URL tal como está en la URL. Y así es como escala nuqs.

Compone diferentes cosas, las aísla juntas y luego las resuelve cuando es momento de actualizar la URL para ti. Así que hagamos que esto desaparezca. ¿Y qué más podemos hacer ahora? Bueno, todavía tenemos un pequeño problema en nuestro código. Si escribo, digamos, love, verás que he enviado cuatro solicitudes de red. Una por carácter. Solo estaba limitando. Eso no es genial.

Así que lo que queremos aquí es el estado final. Cuando dejo de escribir, lo que queremos es debounce. Así que comencemos pasando algunas opciones aquí. Así que puedo hacerlo en un sitio de llamada, opciones de nuqs. Y puedo esparcirlas aquí. Y aquí puedo especificar una opción llamada limitar actualizaciones de URL de debounce. 250 milisegundos serán suficientes. Si te preguntas qué hace esta función debounce, es solo un constructor para un descriptor objeto que define si hacemos debounce o no en el tiempo en milisegundos. Nada mágico aquí. Azúcar sintáctica.

Y lo que esto nos da ahora es algo que si escribo beetles de nuevo, solo envía la solicitud al final con beetles. Genial. Excepto que hay un pequeño problema con esta actualización ahora, porque cuando escribo algo, ves que no pasa nada. No tenemos ninguna retroalimentación de que algo va a suceder. Tengo esta pequeña propiedad is loading aquí, que me da un spinner en la entrada. Así que conectemos esto a una transición. Usa transition de React. Tengo is pending start transition. Puedo conectar is pending aquí. Y ahora necesito saber dónde disparar esta start transition. nuqs tiene soporte incorporado para esto como una opción, así que podría pasarlo aquí. Pero solo se disparará cuando la red esté siendo enviada, la solicitud esté siendo enviada a través de la red. Verás que al final, gira solo un poco.

Lo que queremos mostrar es que algo va a suceder. Queremos mostrar este spinner durante toda la duración de cuando escribo, más cuando el servidor ha terminado de devolver. Lo que podemos hacer es envolver nuestra función de estado de datos en start transition. Puedo hacer esto aquí. Y hay un pequeño truco para la función de estado de datos, devuelve una promesa que se resuelve cuando la URL ha terminado de actualizarse. Así que lo que podemos hacer es async aquí, esperar eso. Y ahora esta transición va a durar toda la duración de la cola de debounce, más el tiempo que tarda el servidor en renderizar.

Así que si voy por love de nuevo, viste que love es un poco corto, así que Beatles, ves el spinner seguir funcionando. Ahí vamos. El pequeño problema que tenemos aquí ahora es que si aumento el tiempo de debounce, lo verás. Si escribo love de nuevo, tarda un segundo en volver. Pero si hago clic en clear, también tarda un segundo antes de que se borre, porque hemos definido esta semántica de debounce globalmente para este hook. Y ahora todas las llamadas a la función de estado de datos están debounced. Eso no es realmente lo que queremos. Queremos hacer debounce cuando escribimos.

Así que puedo mover esta opción del nivel global al nivel de la función de estado de datos y eliminarla de aquí. Y ahora si escribo love de nuevo, tarda un segundo. Pero cuando borro, es mejor. Pero hay otra manera de borrar una entrada. Si escribo love y selecciono todo y presiono backspace, también tarda un segundo. Eso no es genial, pero esto es fácil de arreglar porque tenemos el valor que estamos configurando aquí. Así que podemos elegir cuando realmente estamos escribiendo algunos valores, hacemos debounce. De lo contrario, no lo hacemos. Y ahora si voy por love, un segundo, selecciono todo, backspace, instantáneamente. Mejor. Seguridad de tiempo declarativa. Añadamos algunos favoritos a estas cosas. ¿Qué son los favoritos? ¿Alguna idea? ¿No? Enlaces. Buenos viejos enlaces en los que puedes hacer clic. Preconfiguran tu URL y el resto de tu UI sigue.

¿Cómo se hacen estos? Están codificados de forma rígida. Eso no es genial. Queremos seguridad de tipo para esos también. Así que vamos a nuestro archivo de definición de parámetros de búsqueda y exportamos un nuevo helper. const getAlbumsLink. Y aquí voy a usar algo que en realidad no es parte de nuqs. createTypedLink. Es una utilidad que puedes instalar en tu aplicación porque utiliza la función de rutas de tipo de Next.js. Así que tengo estos nombres de ruta seguros de tipo que puedo conectar a mi conjunto de parámetros de búsqueda.

Y ahora esta función estará fuertemente vinculada a ese nombre de ruta con esos parámetros de búsqueda. TypeSafeRouting. Así que la forma en que se hace internamente, utiliza una API de nuqs llamada serializer. Es lo opuesto al loader. Genera una cadena href a partir de un estado de tipo, estados. Y se vincula a esta definición de tipo de ruta que es generada por mi configuración local de Next.js. Genial. Así que vamos a usar eso en nuestros favoritos. Voy a reemplazar esos con esta función, getAlbumsLink. Y solo tengo que especificar los parámetros de búsqueda aquí. Voy a dejar que la IA haga el resto. Y este. Gracias. Ahora, esto no ha cambiado nada en la salida. Seguimos teniendo lo mismo, pero al menos es seguro de tipo. Si cometo un error, me lo dirá. Eso es mejor. Una cosa que podemos hacer con eso es que tenemos esta consulta y lanzamiento aquí en la URL. Esos son nombres de variables que tienen sentido en toda la aplicación.

Esos son para desarrolladores. Podrían ser un poco verbosos para las URLs. Así que podemos reasignarlos a claves más cortas con nuqs. Podemos usar la función de claves de URL para esto. Claves de URL de eso. Y puedo tener estos nombres de variables siendo reasignados a una clave más corta. Así que mapeo query a queue, release year a year. Y ahora necesito pasar este mapeo a mis otros exports. Así que aquí, allí y en todas partes. Y como ves, la cosa se reinicia porque introduje un cambio disruptivo aquí al renombrar mis claves. Así que ten cuidado con tus cambios disruptivos. Pero ahora tengo estas claves cortas en todas partes, y no he cambiado nada más en mi aplicación. Todos usan estos nombres de variables, pero claves de URL cortas.

Genial. La última cosita que quiero mostrarte es cómo probamos esto. ¿Cómo nos aseguramos de que esto todavía funciona? Tengo este archivo de prueba aquí que usa vtest para probar dos escenarios. Queremos probar que cuando cargamos una URL, nuestros inputs tienen el valor correcto. Así que tengo este adaptador de prueba que simula todo lo que nuqs necesita. Y podemos pasarle un conjunto inicial de parámetros de búsqueda. Y nos aseguramos de que nuestros inputs recojan esos estados correctos. Pero también podemos verificar contra actualizaciones. Así que aquí tengo una función espía de actualización. Que puedo montar mi UI, llenar alguna búsqueda, y luego asegurarme de que la actualización de estado optimista ocurra. Así que esos valores ya tienen el correcto... Esos inputs ya tienen los valores correctos. Podemos asegurarnos de que el spinner se muestre. Y luego, después de un tiempo dado, la URL se actualiza correctamente. Excepto que esto falla de alguna manera. Intenta de nuevo. Esto debería fallar. Ahí vamos.

Esto falla por una razón. Porque primero olvidé cambiar esto a 250 milisegundos. Mi cosa esperaba 250 milisegundos. Pero también falla porque espera que Metal, la query, llegue primero. Y eso es porque en realidad tengo un error allí. Que hice un debounce en este primer input. Pero también necesito hacer un debounce en mi input de release. Así que puedo pasar esto aquí. Y ahora mi prueba pasa. Eso es mejor.

Así que podemos probar nuqs. Es posible. Y simula todo lo que necesitas para ti. Muy bien. Hagamos un resumen. Así que vimos que nuqs utiliza un enfoque declarativo para los parámetros de búsqueda. Tanto en términos de seguridad de tipos como de seguridad de tiempo. Y escala por composición. Así que la declaración y la composición son los principios fundamentales de React. Y nuqs utiliza el mismo enfoque para escalar tu aplicación. Y no es particularmente opinado sobre dónde defines esas definiciones. Puedes hacerlo junto a la página como lo hice yo. O puedes hacerlo junto a los componentes. Y cada componente exporta sus propios comportamientos. Y luego puedes componerlos juntos a nivel de página. Y es incrementalmente adoptable. Puedes comenzar con un useQueryState. Y luego mejorar progresivamente con otras definiciones. UseQueryStates. Derivando tipos.

Y todas estas cosas. Y para concluir, diré que el patrón de estado de URL es poderoso. Y con gran poder viene una gran responsabilidad. Así que mi último consejo antes de irnos sería... Nunca subestimes las query strings. Gracias.

Las primeras preguntas van a empezar a llegar. Pero comenzaremos con la primera. ¿Es de código abierto? ¿Y cómo ha sido mantener el código abierto, si es así? Sí, es de código abierto. Tenemos casi 10,000 estrellas en GitHub. Y acabamos de superar un millón de descargas semanales. Así que sí, va bien.

¿Cómo ha sido mantenerlo? Ha sido un viaje salvaje, eso es seguro. Porque hago esto en mi tiempo libre. Tengo un negocio freelance. Y hago esto por las noches y los fines de semana. Me encantaría poder dedicar más tiempo a hacerlo a tiempo completo. Pero con el tiempo, he sido principalmente yo trabajando en ello.

Y ahora mucha gente está empezando a contribuir a ello. Gracias, Dominic. Ha estado contribuyendo mucho a ello. Y es realmente bueno porque ahora cambia el rol de implementar a orquestar. Y es una dinámica diferente. Pero es realmente interesante ver cómo la gente trae nuevas ideas al proyecto, y cómo componerlas con una visión global de hacia dónde queremos ir con esto. Gracias por eso.

Ha llegado otra pregunta. ¿Puedes integrar con esquemas de validación como Zod? Entonces, sí, con adaptadores, con la transformación de la validación. El problema de la validación es algo que mucha gente ha preguntado. ¿Soportas Zod nativamente en nuqs? Y justo antes de la versión 4.1 de Zod, la respuesta era no. Porque las bibliotecas de validación como Zod, o cualquier cosa basada en esquemas estándar, carecen de la transformación inversa de volver de un tipo de dato a una cadena. Si es algo simple como un número o una cadena en sí, eso no suele ser un problema.

Si empiezas a integrarlo con objetos, como una opción de ordenación, como tienes la clave contra la que ordenas, y la dirección. Quieres ordenar estos en una sola cosa. Y generas un objeto a partir de eso. Necesitas la transformación inversa para reencodarlo en la URL cuando escribes en ella. Y así, las bibliotecas de validación podrían darte una transformación en un sentido, pero no en el otro. Zod 4.1 salió con Codex, que te permite hacer esta transformación bidireccional entre dos tipos de datos, incluyendo serialización y deserialización.

Y ahora podemos soportar estas cosas, que hacen tanto validación como SERD, serialización deserialización. Así que hay otros que hacen esto, como effect schema también lo hace. Y sí, sería posible usar estos siempre que tengan el flujo bidireccional. Genial. Sí. Otra, ¿cómo manejarías un escenario donde quisieras retrasar la aplicación de tu consulta? Por ejemplo, si tus filtros están en un modal o un cajón y quieres que se apliquen todos a la vez. Entonces lo que puedes hacer es desacoplar el estado de la URL, las actualizaciones de la URL y las actualizaciones del estado local están desacopladas. Y tienes estas semánticas de tiempo declarativas que puedes añadir. Así que throttle o debounce. Y un truco es establecer estos valores en infinito. Y nunca actualizará la URL hasta que hagas otra actualización con la tasa de throttling estándar.

Y eso simplemente empujará todo lo que está actualmente en memoria en tus estados locales hacia la URL de una vez. Así que puedes hacer un poco como un formulario. Esencialmente, lo que estás tratando de hacer con este tipo de UI es un formulario. Intentas poner estados localmente en tu cosa. Y luego al final, presionas enviar y envía todo. La funcionalidad básica de los formularios siempre fue enviar las consultas, como los valores en la cadena de consulta, antes de que tuviéramos reactividad del lado del cliente.

Así que usa un formulario, si eso es lo que estás tratando de lograr. O si realmente quieres hacer esto, puedes evitar la actualización de la URL configurándola en infinito. ¿Y nuqs maneja la compresión de los parámetros de consulta? No lo hace por defecto, pero puedes crear un analizador personalizado. Así que tenemos muchos analizadores integrados, pero también puedes crear el tuyo propio. Y definitivamente puedes crear... Algunas personas han hecho eso, de hecho. Crear un analizador personalizado que comprima al escribir y descomprima al leer.

Y dado que los analizadores son componibles, podrías tener algún tipo de analizador de middleware que haga este tipo de compresión y lo canalice a otro analizador que se encargue de transformar adecuadamente en un tipo de dato que tu aplicación necesite, como un objeto o un número, algo más grande, supongo, porque generalmente la compresión se tratará de almacenar grandes valores en la URL. Lo principal es recordar que está limitado en espacio. Así que no intentes poner demasiado allí. Genial. ¿Y hay sinergias con TanStack?

Router. {{^}}Router. Sí. TanStack Router utiliza un enfoque muy similar en términos... Lo hacen un poco mejor en términos de seguridad de tipos porque tienen más control sobre todo el sistema de enrutamiento. Definen el comportamiento de los programas de búsqueda a nivel de página, y eso les da la capacidad de hacer enlaces seguros por tipo integrados en el navegador. Solo tienes que especificar a qué rutas quieres enlazar, y tienes el conjunto de programas de búsqueda que coincide con el esquema que definiste. Esto es increíble. Funciona realmente bien. La cuestión es que nuqs utiliza un enfoque muy similar, pero tiene personalización de serialización por clave. Apoyamos TanStack Router en términos de cargar esos hooks. Así que principalmente para personas que tienen aplicaciones TanStack Router slash start para poder cargar componentes que usan nuqs en sus aplicaciones, aún te recomendaría usar las APIs de TanStack Router para la gestión de programas de búsqueda. Si estás construyendo con TanStack Router, probablemente tendrás una mejor experiencia con esto. Y sí, es similar en muchos aspectos, y se componen juntos. Necesito trabajar en hacerlo funcionar un poco mejor.

Bien, agradable. Sí. De acuerdo. ¿Y nuqs previene ataques de inyección de scripts en la consulta para nuestra aplicación? Si me sigues en Twitter, notarás que hace dos días hice un ataque de inyección de scripts yo mismo para mostrar que era posible, y no hagas eso. Así que no querrás evaluar nada en tu analizador, eso no sería genial. No hace nada por defecto por sí solo, pero por ejemplo, un gran ejemplo de esto es si quieres pasar un redireccionamiento, muestro esto en el intercambio de datos de clientes y servidores de URL. Si quieres pasar un redireccionamiento a tus clientes, quieres asegurarte de pasarlo contra el origen, y o que comience con una barra, cosas así. Así que previene redirecciones abiertas en nuestra aplicación. Así que nuqs no te da esto por defecto, pero puedes crear un analizador que haga exactamente eso, como seguro desde o algo así.

¿Y nuqs se lleva bien con las bibliotecas de gestión de estado global del lado del cliente como Zustand, Redux? Zustand, tengo un ejemplo para hacerlo funcionar con Zustand. Como si quisieras, por ejemplo, en una función de Zustand leer desde la URL, puedes realmente usar el cargador para esto. No está limitado al lado del servidor. Puedes usar cargadores prácticamente en cualquier lugar para este análisis único de la URL. Así que haces un loader.location.search, por ejemplo, y eso te dará el estado actual que está en la URL en tu función de Zustand. Pero sí, por ejemplo, Jotai tiene un sistema incorporado para sincronizar con la URL.

Pero sí, por ejemplo, Jotai tiene un sistema incorporado para sincronizar con la URL. Redux no estoy seguro, pero Redux es básicamente esencialmente lo mismo que Zustand en términos del flujo de datos. Así que funcionaría esencialmente de la misma manera.

Y antes de cerrar, debido al tiempo, ¿puedes responder rápidamente, puede manejar arrays? Sí, puede de muchas maneras, gracias a Dominic. Podríamos manejar arrays en una forma compacta. Así que tienes una clave y luego múltiples valores separados por un carácter separado, como una coma, por ejemplo.

Pero recientemente, gracias a la contribución de Dominic, ahora podemos tener la repetición de claves. Así que tienen foo igual a bar y foo igual a egg, y luego tienes bar egg en un array. Así que ahora podemos hacer ambas cosas. Puedes elegir qué método quieres usar. Genial. Se nos acabó el tiempo. Muchas gracias. Muchas gracias. Y si quieres hablar con él, está en la sección de preguntas y respuestas.