4dim / Notas
La pantalla ya lo comprobó, y eso no vale
Alguien deja la consola abierta al irse a casa, vuelve al día siguiente y el botón de responder sigue ahí — pero la ventana de 24 horas se cerró de noche. Qué comprobación decide, cuál es cortesía, y dónde más aparece la trampa.
La pestaña que lleva abierta desde ayer
Si tu aplicación decide qué botones enseñar según el estado de algo que cambia con el tiempo, esta nota describe un fallo que no se reproduce en pruebas y que tus usuarios ven todas las semanas.
La escena: alguien deja la consola abierta al irse a casa. Al día siguiente vuelve, ve la conversación de un cliente y el botón de responder. Escribe, envía.
Y falla, porque la ventana de 24 horas de Meta se cerró durante la noche. El botón estaba ahí porque se pintó ayer, cuando la ventana estaba abierta.
La pantalla ya lo comprobó. Y eso no vale: lo comprobó en un momento que ya pasó.
No es un fallo de la pantalla. Es que una pantalla es una foto, y las fotos envejecen. El estado que un navegador tiene en la mano es siempre del pasado; la única pregunta es de cuánto.
Se comprueba otra vez, en el momento de actuar
La regla es corta: quien decide es la comprobación hecha en el momento de mandar, no la que pintó el botón.
Las tres formas de escribir fuera de la ventana —plantilla, etiqueta, lo que corresponda a cada canal— vuelven a preguntar por su cuenta. Las tres. Aunque la pantalla ya lo hubiera hecho.
Y no es una duplicación que sobre, porque las dos comprobaciones hacen cosas distintas:
| Comprobación | Para qué sirve | ¿Se puede confiar? |
|---|---|---|
| Al pintar la pantalla | No ofrecer un botón que va a fallar | No: envejece |
| Al mandar | Que no salga lo que no debe salir | Sí: es ahora |
La primera es cortesía: evita ofrecer algo que fallará. La segunda es la que decide. Quitar la primera empeora el producto; quitar la segunda lo rompe.
Lo que cuesta no comprobar dos veces
En este caso concreto, el coste de fiarse de la pantalla no es un error feo: es dinero y reputación de la cuenta.
Un mensaje enviado fuera de la ventana lo rechaza Meta. Ese rechazo queda registrado y afecta a la calidad de la cuenta. Con la calidad baja, bajan los límites de envío del negocio.
Y hay una segunda cara más cara todavía: en algunos canales, un envío rechazado no es gratis. Se paga el intento.
Así que la pregunta que hay que hacerse ante cualquier estado que se pinta en pantalla es: ¿qué cuesta actuar sobre un estado viejo?Si la respuesta es «un mensaje de error», la comprobación al actuar es opcional. Si es dinero, una sanción o algo irreversible, no lo es.
Por qué esto vive aparte de las demás acciones
Un apunte de organización que enseña a clasificar el propio código.
Fijar una conversación, archivarla, cerrarla: son acciones sobre la conversación. Cambian algo nuestro, en nuestra base, y se deshacen.
Mandar un mensaje fuera de la ventana no es eso. Es un envío, y un envío arrastra tres cosas más: el permiso de quien envía, la comprobación del plazo, y el veredicto de Meta sobre lo que se manda.
Ponerlos juntos porque «los dos son botones del chat» es agrupar por dónde están en la pantalla. Lo correcto es agrupar por qué arrastran: lo reversible con lo reversible, lo que sale hacia fuera con lo que sale hacia fuera.
Separa repartir una conversación de borrarla por lo mismo: el criterio no es dónde está el botón, es qué pasa al pulsarlo.
Dónde más aparece esta trampa
Merece la pena tener el catálogo, porque el mismo fallo tiene muchas caras y todas se descubren tarde.
- Un plazo que expira. Ventanas de mensajería, tokens, enlaces de invitación, sesiones. Lo que valía al pintar puede no valer al pulsar.
- Un permiso que le quitaron a alguien. Con la pestaña abierta, sigue viendo los botones de lo que ya no puede hacer.
- Un saldo o un inventario. Dos personas mirando la misma pantalla ven la misma unidad disponible.
- Algo que otro ya hizo. La conversación que aparece sin dueño lleva veinte minutos asignada a un compañero.
En los cuatro, el remedio es el mismo y no es refrescar la pantalla más a menudo: es comprobar en el momento de actuar, en el servidor, con la condición puesta en la propia operación de escritura.
Qué hacer entonces
- Deja una pestaña abierta un día entero y prueba los botones.Es la prueba que nadie hace y donde están estos fallos.
- Pregúntate qué cuesta actuar sobre un estado viejo. Si cuesta dinero o es irreversible, comprueba al actuar.
- Pinta con la comprobación y decide con otra. No son duplicadas: hacen cosas distintas.
- Pon la condición dentro de la escritura. Comprobar y después escribir deja una rendija entre las dos.
- Agrupa tu código por lo que arrastra, no por dónde está el botón. Lo que sale hacia fuera merece su propio sitio.
Esta nota sale de nuestro trabajo en AI-CRM Connection.