Las macros, y qué esconden

Qué genera

Y el paso 3 explica algo que se acepta sin pensar: un comando puede recibir el estado o la ventana como argumento y el frontend no los manda — porque la macro los resuelve del contexto, no del mensaje.

Por qué sus errores son confusos

Tres razones que se acumulan:

Y el truco que resuelve la mayoría: buscar en el mensaje el nombre de tu propio tipo. El compilador siempre lo menciona, y ahí está la causa real — normalmente que le falta la capacidad de serializarse.

Los cuatro errores frecuentes

Con su causa y su arreglo:

• Un tipo que no se puede deserializar → falta derivar la capacidad correspondiente. Nivel 15.1.
• Un tipo de error que no se puede serializar → nivel 16: el error tiene que poder cruzar.
• Un comando asíncrono con una referencia → el compilador exige que lo que se lleva a una tarea pueda moverse; la corrección es tomar lo que hace falta antes o usar la variante bloqueante. Nivel 42.1.
• Y un argumento que el frontend no manda → si no es de los especiales del paso 3, es un desajuste con la llamada.

Los dos primeros son la mayoría y los dos se arreglan con una línea, cuando se sabe qué mirar.

Leer el código generado

Y la operación que convierte un error confuso en uno obvio: expandir la macro y ver el resultado.

• Hay herramientas que muestran el código tras la expansión, y con eso el envoltorio deja de ser invisible.
• Y leerlo una vez explica la mitad de las dudas: cómo se extraen los argumentos, dónde se comprueba qué, y qué se hace con el resultado.
• Merece hacerlo una vez aunque no haya ningún error, por lo mismo que el nivel 74.5: entender lo que hay debajo hace predecible lo de arriba.

Y es especialmente útil con un error que no se entiende: ver el código real que no compila suele hacer evidente qué falta.