Support flash messages [integrate #62]

[tmattio]

Flash messages are a common way to display success or error notifications to users in server-side rendered applications.
Dream already has a middleware to support sessions, which Flash messages are a specialization of, so it would be great to have a middleware and a set of API to support flash messages.

Additionnally, helpers to add flash messages in Eml templates would be really useful. For reference, here's Phoenix documentation on this: https://hexdocs.pm/phoenix/controllers.html#flash-messages. The templates look like this:

<p class="alert alert-info" role="alert"><%= get_flash(@conn, :info) %></p>
<p class="alert alert-danger" role="alert"><%= get_flash(@conn, :error) %></p>

[aantron]

Definitely yes! I skipped this for now because I wasn't ready to design good flash helpers myself. Any more good precedents very welcome.

[jsthomas]

Another precedent that might be of interest is Django's messages framework. Below is my quick summary of that page.

Messages have three main parts: The body of the message, which is a string, the level (debug, info, success, warning or error), and one or more string-valued tags. The level is always provided as one of the tags, and custom levels are possible. Messages can be stored in different ways (in the database or with cookies, for example).

The two functions application developers are expected to use to manage messages look like:

add_message(request, level, message, extra_tags='', fail_silently=False)
get_messages(request)

the latter gives you a list of messages to iterate over. There are also convenience functions for creating messages at a particular level (e.g. messages.info(request, "hello")). There is functionality for disabling messages below a certain level (for example, if you don't want debug messages while running in production). The fail_silently option on add_message decides what to do if the messages framework is entirely disabled.

By default all of the flash messages get cleared when a response is processed (so they only show up once) but the framework allows app developers to mark a message so that it won't be cleared.

I'm interested in helping with this issue, if I can. That could mean continuing to research other precedents or putting together a prototype PR for discussion.

[aantron]

Thanks @jsthomas, that saved a lot of research time for me! I would welcome a prototype PR.

[aantron]

@jsthomas The example now has a writeup, is in the playground, and I finished up the docs for the feature.

Thanks again for actually implementing it in #62!

[jsthomas]

Awesome! This comment in the example is helpful, I learned something new here:

The total size of all flash messages attached to a request has a soft limit of about 3072 bytes. This is because cookies are generally limited to 4096 bytes, and Dream ends up encrypting flash messages and encoding them in base64, which blows up their original size by 4/3.