Should there be a way to read flash messages that were set in the current request?

[aantron]

This could be useful sometimes, to use the same code that renders flash messages, to render some feedback that was generated during handling of the current request (rather than across a redirect, as is typical for flash messages).

At the very least, we should find out if any major frameworks allow this implicitly or explicitly. Frameworks such as:

• Phoenix
• Laravel
• Django
• Whatever Express has for flash messages in its ecosystem.

cc @thangngoc89

[thangngoc89]

I take a look at connect-flash and there is an (awkward) way to read flash message in current request:

req.flash("flash_name", .....) // this set flash
res.locals.flash_name = req.flash(); // this assign flash to current request, something connect-flash middleware should have handled in the next request
res.render(......)

Unanswered question: Will flash_message be available in the next request after being read here?

[tcoopman]

This is from the phoenix documentation (https://hexdocs.pm/phoenix/controllers.html#flash-messages)

defmodule HelloWeb.PageController do
  ...
  def index(conn, _params) do
    conn
    |> put_flash(:info, "Welcome to Phoenix, from flash info!")
    |> put_flash(:error, "Let's pretend we have an error.")
    |> render("index.html")
  end
end

So this is not just on redirects but also with the current render

[outkine]

In Scala Play, the flash is applied onto the Result type, so it can only affect the next request. In fact, the framework will warn you if you (erroneously) try to write something like this:

  def index = Action { implicit request =>
    Ok(views.html.index()).flashing("info" -> "Example flash")
  }

Personally I think that an API that is agnostic about how you configure the flash seems cleaner, and makes this confusing no-op Scala code impossible.

[aantron]

an API that is agnostic about how you configure the flash

Can you clarify what you mean by this?

[outkine]

Going off of the examples in this thread, that means that something analogous to the flashing method can exist not only on the response object (like in Scala), but also on the request object as well. In the second case it affects the template rendered in the same request, and in the first case it affects the next request.