Mostrar notificaciones después de cada acción del usuario es parte esencial de cualquier aplicación web moderna. Con flash messages en Flask puedes avisar cuándo se creó una nota, cuándo ocurrió un error o cuándo algo necesita atención, todo usando sesiones y cookies del propio framework.

Esta funcionalidad viene integrada en Flask y aprovecha las sesiones para compartir información entre requests del mismo usuario. Si guardas un mensaje en una vista, podrás mostrarlo en la siguiente carga de página sin lógica adicional.

¿Qué son los flash messages y para qué sirven en Flask?

Los flash messages son mensajes temporales que viajan entre requests a través de cookies firmadas. Sirven para confirmar acciones como crear o eliminar una nota, o para reportar errores cuando algo falla en el guardado.

¿Qué es un flash message en Flask? Es un mensaje corto que se guarda en la sesión del usuario y se muestra en el siguiente request. Se usa para confirmar acciones o reportar errores después de un POST.

Como la información viaja por medio de una cookie, Flask exige configurar un secret key en la aplicación. Esa clave encripta el contenido de la cookie y, sin ella, el framework lanza un error porque no puede garantizar la seguridad de los datos del usuario.

¿Cómo configurar el secret key para encriptar las cookies?

El primer paso es asignar un valor a app.secret_key. Puede ser cualquier cadena, pero debe existir para que Flask pueda firmar las cookies de sesión donde se almacenan los mensajes.

Sin esa configuración, intentar usar flash provocará un error inmediato. Es un requisito mínimo de seguridad antes de habilitar la funcionalidad.

¿Cómo enviar un mensaje con flash desde una vista?

Después de configurar la clave, importa la función desde el framework con from flask import flash. Ojo con la diferencia: Flask es el framework y flash es la función para mensajes, dos cosas distintas que conviven en el mismo paquete.

En la vista de creación, justo después de guardar la nota, llama a la función pasándole dos argumentos:

• El texto del mensaje, por ejemplo "Nota creada".
• La categoría, por ejemplo "success".

La categoría es clave porque te permite diferenciar el tipo de mensaje en el frontend. Un success puede pintarse verde, un error rojo y un warning amarillo. La lógica visual queda separada de la lógica del servidor.

python from flask import flash

después de crear la nota

flash("Nota creada", "success")

¿Cómo mostrar los flash messages en un template con Jinja?

El siguiente paso es renderizar los mensajes en el template que se carga después de la acción. En el caso del proyecto de notas, ese template es notes/home, donde vive la lista.

Dentro del archivo, fuera del ul de las notas, se usa la sintaxis estándar de Jinja con llaves y signos de porcentaje. La función get_flashed_messages recupera todos los mensajes almacenados en la cookie de sesión.

jinja {% with messages = get_flashed_messages(with_categories=true) %} {% if messages %} <ul> {% for category, message in messages %} <li class="{{ category }}">{{ message }}</li> {% endfor %} </ul> {% endif %} {% endwith %}

El bloque with guarda en la variable messages lo que retorne la función. Si no hay mensajes, el if evita renderizar nada. Si los hay, se itera con for y cada elemento expone dos valores: la categoría, que se inyecta como clase del li, y el mensaje, que se imprime como contenido.

¿Por qué necesito with_categories=true al recuperar los mensajes?

Si llamas a get_flashed_messages sin parámetros, la función devuelve solamente los textos. Cuando intentas desempacar dos valores en el for, Jinja lanza un error porque no encuentra las categorías.

¿Cómo recupero la categoría junto al mensaje? Llama a get_flashed_messages(with_categories=true). Sin el true, la función devuelve solo strings y el desempaquetado en el for falla.

Pasar with_categories=true indica explícitamente que quieres tuplas con categoría y mensaje, lo que habilita el estilo diferenciado por tipo.

¿Cómo extender los flash messages a toda la aplicación?

Una vez que la mecánica funciona en creación, conviene replicarla en eliminación, edición y validaciones. Cada acción importante del usuario debería generar feedback visual.

Algunas categorías útiles para cubrir los escenarios más comunes:

• success para confirmaciones de creación, edición o eliminación.
• error para fallos de guardado o problemas de servidor.
• warning para advertencias previas a una acción destructiva.

El diseño base luce inconcluso porque solo aplica una clase CSS. El siguiente paso natural es integrar Tailwind CSS para mapear cada categoría a un set de utilidades visuales: fondos, bordes y tipografía coherentes con el resto de la interfaz.

Instala Tailwind, agrégalo a la lista de notas y dale estilo a cada tipo de mensaje con un color distinto. Cuéntame en los comentarios qué categorías nuevas vas a sumar a tu aplicación.