Restyle & Refactor Flash Messaging

[mbwatson]

Summary

Restyles and refactors the flash message (snackbar notification) system to improve UX, styling, and maintainability.

Changes

• FlashMessage component — Reworked styling: messages now use bordered, light-tinted backgrounds (color-mix) instead of fully solid fills, with dark text for better readability. Added a dedicated WarningIcon for warning-type messages. Auto-hide duration is now type-aware (success/info auto-dismiss; warning/error persist until manually closed), supporting reading longer error messaging. Layout updated to span the content area instead of being small and centered.

• FlashMessageContext — Replaced useState-based queue with useCallback-driven addFlashMessage/removeFlashMessage functions. Each message now receives a unique id for stable removal. Added a useFlashMessaging custom hook with a guard for usage outside the provider.

• FlashMessageContainer — Now receives messages and onClose as props, rendering the list internally instead of accepting children. Supports a disableAutoHide prop for debugging.

• DropZone — Minor formatting fix: newline after the "Error uploading file:" header for cleaner multi-line error display.

---

these screenshots show the busiest error message returned from the API, before and after this PR:

before

after

[davidborland]

This looks much nicer IMO. A couple of questions:

1. Does the error display have a max height? Is it scrollable? Just wondering if there might be a situation where there are enough errors that some might get cut off, either due to max heigh on the error display, or a screen with a low y resolution.

2. Is the error message cut and pastable? I presume so, but wanted to double check.

[mbwatson]

1. at this point, no scrolling and no max height, but these are good ideas.
2. yes the errors can be copied with the normal manual method, but a copy button would be a nice touch--especially for the error messages.

i'd be happy to implement these ideas.

[davidborland]

I think (1) is the most important, as I believe the primary problem the client was having was not being able to see all of the errors. I would consider (2) a nice to have, but not as crucial.

[davidborland]

@mbwatson Can you upload a screenshot with the changes?

[mbwatson]

@davidborland yep, here's one! you'll see i've opted to tuck them off to the right side. on a large screen size, when the tray fills up with notifications, the overflow scroll was not too user friendly when these were full-width. however, it does flip to full-width on a smaller screen size. the higher contrast text and color changes are what you saw previously.

[davidborland]

This looks the same as the previous "after" screenshot to me. Is there a difference between them? Could you show an example of what it looks like with the scroll?

[mbwatson]

yeah i replaced the "after" image in the original description with the new "after" image. you can step through the edited version to see the original.

you can see the scrolling container in this recording:

Screencast.from.2026-05-05.07-44-22.webm

[davidborland]

Ah, okay. I was thinking the individual error message components would be scrollable, but the container that holds the error messages is scrollable? That probably make sense if the issue is multiple error messages stacking, as opposed to a single error message that has too many lines such that it gets cut off.

[davidborland]

Looks good to me