Deferred message loading #525

Open
opened 2026-01-17 11:43:55 +00:00 by mpeltriaux · 0 comments
Owner

Status quo

On server side most of the HTML is created to be delivered in a single response to the client. We could think about improving performance for info/success/error messages even further (we did partially for geometry conflicts in #503 ) by refactoring their rendering into an async call using htmx, just we did with the parcel detail view of a geometry.

Idea

Think about a way to properly 'collect' messages for certain views. Remember: Some messages are temporary (e.g. most success messages like 'sucessfully created entry xyz') and only visible after a specific action (e.g. saving a new entry). Others are permament like most error or info warnings.
Try to find an approach to fetch all types of messages in an appropriate and logical way without too much overhead/overengineering.

# Status quo On server side most of the HTML is created to be delivered in a single response to the client. We could think about improving performance for info/success/error messages even further (we did partially for geometry conflicts in #503 ) by refactoring their rendering into an async call using htmx, just we did with the parcel detail view of a geometry. # Idea Think about a way to properly 'collect' messages for certain views. Remember: Some messages are temporary (e.g. most success messages like 'sucessfully created entry xyz') and only visible after a specific action (e.g. saving a new entry). Others are permament like most error or info warnings. Try to find an approach to fetch all types of messages in an appropriate and logical way without too much overhead/overengineering.
mpeltriaux added the enhancement label 2026-01-17 11:43:55 +00:00
mpeltriaux self-assigned this 2026-01-17 11:43:55 +00:00
Sign in to join this conversation.