Renderizado de Datos que No Coinciden

Hola, soy Tom, y quiero hablar sobre la representación de datos que no coinciden. Así que digamos que estás representando una página web. Y tal vez estés usando componentes del servidor, tal vez sea un componente del cliente que está haciendo SSR, tal vez estés de vuelta en el mundo de PHP o Python o Perl o Ruby, y necesitas obtener algunos datos.

Probablemente los obtendrás de una base de datos. Y entonces lanzas tu primera consulta SQL, que es un select para obtener todos los usuarios que están en un canal de chat dado, y luego lanzas otra consulta SQL para obtener todos los mensajes en ese canal. Y ahora tienes los datos que necesitas. Puedes simplemente representar esta cosa.

Esto es discourse o mi favorito, Zulip. Y en el centro, tenemos un montón de mensajes en un canal de chat y a la derecha, tenemos los usuarios que están en ese canal de chat. Pero con suerte, con esa primera descripción del problema, tu mente fue a, ah, pero ¿están esas dos consultas SQL en la misma transacción? ¿Son como aquí? ¿Estas son dos consultas que se ejecutan en transacciones separadas o están en la misma transacción? Esa es información importante para nosotros porque nos dice qué podemos hacer con esos datos.

¿Qué pasa si primero lees tus usuarios y luego se agrega un nuevo usuario al canal y ellos también publican un mensaje y luego lees tus mensajes? Estos agregar un usuario y agregar un mensaje podrían ser una acción atómica que podría suceder juntos. Podría ser un mensaje de unión o algo así. Y si los leemos así, leemos usuarios y luego leemos mensajes, y asumimos que cada mensaje tiene un usuario correspondiente, vamos a estar decepcionados. Este es uno de esos casos donde, bueno, veamos. ¿Qué podría pasar? Tal vez sea solo una inconsistencia visual. Tal vez todo lo que sucede es que ves esta página y dices, oh, eso es curioso. Hay una persona aquí, pero no hay nadie correspondiente en esa cosa de usuarios. A menudo no importa. Y a menudo lo que haces, lo que nuestros usuarios están entrenados para hacer es actualizar la página.

Para bien o para mal, así es como siempre ha funcionado la web. Como, uh-oh. Tal vez es eventualmente consistente. Actualizas y todo está mejor. Pero tal vez esa inconsistencia visual es un gran problema. Tal vez esa es la diferencia entre pensar que tengo mis boletos de Taylor-Tomlinson y no tengo mis boletos de Taylor-Tomlinson. Tal vez veo algo, es una compra, y algo me confunde allí y realmente me preocupo como usuario. Pero tal vez no son dos interfaces de usuario separadas. Tal vez es una interfaz de usuario y tengo código que espera ambas piezas de datos. Estoy asumiendo que cada mensaje tiene un usuario correspondiente, y de lo que trata esta charla es que es tu trabajo saber si esos datos podrían ser inconsistentes.

Y conoces este error de TypeScript que vemos mucho, donde tienes un map y dices, oh, creo que es un map de cada usuario. Y miras allí para obtener un usuario por ID y dice, uh-oh, lo que buscabas no está allí, y siempre simplemente pones un signo de exclamación al final porque, por supuesto que está allí. Se suponía que esta era una lista completa. Bueno, en este caso, no podemos ignorar ese mensaje de TypeScript. ¿Qué pasa si nos faltan usuarios? Y no podemos ignorarlo porque esto es lo que sucede, ¿verdad?

Esto es algo bastante malo. Si es mejor o peor que una inconsistencia visual, supongo que es debatible. Pero en general, quiero decir que es peor. Así que hay una idea interesante, llamada transacción. Y si estas dos consultas hubieran estado en la misma transacción, no estaríamos preocupados aquí. Y entonces, si obtuviéramos un error, sería un error muy accionable. Sería, oye, algo está fundamentalmente mal con tu modelo de datos. Si tu base de datos devolvió estas dos listas, y terminaste con un mensaje sin usuario, hay algo realmente mal aquí, ¿verdad? En lugar de la alternativa de que los usuarios simplemente se quejan a veces de que, ah, parece que los datos están cargando mucho. Y cuando esa es cómo una inconsistencia, una inconsistencia fundamental en tus datos se manifiesta, porque has codificado alrededor de algunos usuarios simplemente no tienen algunos mensajes no tienen usuarios. Y eso está bien. Sabes, lleva más tiempo encontrar problemas en tu sistema. Los datos consistentes pueden significar que esos errores del lado del cliente son significativos. Pero no siempre puedes tener datos consistentes. Tal vez estés obteniendo estos datos de múltiples bases de datos o varias APIs. Así que el trabajo de ti como desarrollador front end o de React aquí es saber que estos son consistentes.

Ahora vamos a hablar de React. Resulta que, si no estás usando tu WSGI, esto empeora. los clientes ricos empeoran todo. Quiero decir, mejoran las experiencias de usuario, pero nos lo ponen más difícil. Porque ahora, digamos que estoy mirando mi lista de mensajes, y envío un nuevo mensaje, y luego elijo revalidar. Elijo hacer una solicitud API para obtener la nueva lista de mensajes. Así puedo tener una lista de mis mensajes en este canal que incluya el que acabo de enviar. Pero luego no actualizo los usuarios. Y ahora, si esos dos están desactualizados, podrían estar desactualizados durante, ¿qué, 30 segundos o algo así? Una vez que estamos actualizando algunos datos, pero no todos nuestros datos en el cliente, y se supone que esos datos deben ser combinables, ya no es si, es cuándo.

Cada vez que encontramos un caso donde alguien envía un mensaje y ya no está, ya sabes, cualquiera que se unió al canal en los últimos 30 segundos podría causar ese error en el front end. Una vez más, realmente no podemos ignorar este error de TypeScript ahora. Y las actualizaciones en vivo empeoran todo. Nuevamente, mejoran las cosas. Pero hacen que sea más importante para nosotros razonar sobre la consistencia. Tal vez estés obteniendo nuevos datos periódicamente. Una buena manera de hacer esto es con React Query. Y digamos que estamos siendo realmente cuidadosos aquí. Y React Query te permite usar temporizadores o visibilidad de pestañas o lógica de invalidación manual para decidir cuándo enviar esas solicitudes de obtención, actualizar los nuevos datos. Y digamos, solo ten cuidado, estamos invalidando todo. Así que no nos encontraremos con que los mensajes son nuevos, pero los usuarios son antiguos. Son todos nuevos todo el tiempo. Pero incluso si los obtenemos y los obtenemos al mismo tiempo, las solicitudes podrían terminar en diferentes momentos. Y ahora vamos a tener estos pequeños destellos en la interfaz de usuario donde, oh, tenemos los nuevos usuarios, vamos a renderizarlos. Oh, tenemos los nuevos mensajes. Y tal vez no sean destellos molestos, pero son una indicación de intentar renderizar el nuevo conjunto de usuarios con el antiguo conjunto de mensajes. Así que muchos renders, no necesariamente destellos, pero muchos renders podrían significar muchas oportunidades para que esos datos inconsistentes nos afecten.

Y si esto suena familiar, tal vez estabas usando React cuando teníamos que pensar más sobre actualizaciones por lotes inestables, cuando teníamos que decir, ya sabes qué, tengo dos set states y no se llaman como resultado directo, un resultado sincrónico de una acción del usuario.

Y así es mi trabajo notar eso y si no rodeo estos con, si no agrupo estas actualizaciones, la primera actualización de conjunto se ejecutará primero y volveré a renderizar y luego la siguiente se ejecutará. Y no veré ese destello en la pantalla, pero ejecutaré ese código. Y si ese código incluye esa unión del lado del cliente, voy a tener problemas. No tenemos que hacer esto más desde React 17, ¿verdad? Las cosas son mejores, pero sigue siendo un problema para algo como fetch, donde obtienes estos datos, obtienes esos datos. Y entre la resolución de esas dos obtenciones, tienes datos inconsistentes.