Why does the order of session, redirect, flash, etc matter?

Welcome to the forum!

By the time Phoenix.Controller.redirect/2 returns the 302 HTTP response has already been sent.

https://github.com/phoenixframework/phoenix/blob/v1.4.10/lib/phoenix/controller.ex#L392-L400

So modifying the conn structure afterwards will have no effect on the response.

You can’t saddle the horse when it has already bolted out of the barn.

Thank you so much for your response; really appreciated! Coming from a Haskell world, I’m so used to Monads and pure functions.

I can’t see why do you think that because of that kind of behavior that function is not pure (not even sure if that’s what you think too). I mean, the pipe operatore (|>) does get the left argument and send as the first parameter on the right function, so calling put_flash right in the beggining and calling in the end will call it with 2 different params, since in the latter put_session and redirect would return a new, altered, Plug.Conn.

Haskell (and Elm) is singleminded in its pursuit of purity. Functions like put_session and redirect could exist but rather than directly (and rather imperatively) interacting with the HOW (horrible outside world) those functions would simply register the intent to interact with the HOW somewhere inside the conn. It’s only when the completed conn is handed over to the runtime that those interactions with the HOW happen under the runtime’s full control.

The Clojure community often talks about how immutability helps them to push side effects to the edge of the system. This effect is captured architecturally in the Ports and Adapters architecture (see Functional architecture is Ports and Adapters by Mark Seemann).

The way put_session and redirect in Phoenix work aren’t consistent with a functional core imperative shell kind of approach and could be surprising to somebody coming from a background of functional design which practices a higher level of purity.

Well, I still cannot see the functions there interacting with the HOW in any other way than actually receiving the params, and if that is what you mean by interacting with the HOW, well it must be really tedious to do anything in Haskell. But well, I don’t know much of it, so maybe I should invest a bit on learning it before asking those questions.

Yeah, I know about that, I was just really not getting the specific case there. I mean, I know BIFs, NIFs and processes can introduce side effects, but how put_session and redirect do that? This specific part of the code in isolation is pure as far as I can tell: they receive the params, and return the result, if the same params were given again and again to the same function, they would still get the same result over and over. Where is the side effect? Where the HOW gets in the game for that case?

well it must be really tedious to do anything in Haskell.

It would be tedious to do something like that in Erlang/Elixir.

Given how Haskell embraces monads (less intrusively in Elm) it is actually relatively simple but it does require a significant shift in thinking. “Regular” programming is like flying the plane yourself - programming in Haskell is more like filing a flight plan and having the autopilot do all the dirty work.

Where is the side effect? Where the HOW gets in the game for that case?

• put_session stores information in session storage which depending on configuration is either Plug.Session.ETS or Plug.Session.COOKIE. Putting a value into an ETS table is interacting with an external mutable entity and therefore classifies as a side effect.
• redirect sends the response. To do that it has to interact with the web server which is part of the HOW. And sending the response is a side effect.

Update: looking at the code put_session simply updates the conn struct - so the interaction with the session store is actually happening at the edges (via the plug instantiation).

It’s the call to the session plug that fetches the state from the session store and places it in the conn. At the same time before_send is registered to save the session state back to the store just before the response is sent.

https://github.com/elixir-plug/plug/blob/v1.8.3/lib/plug/session.ex#L60-L104

Right, in that case I agree, but the default is the cookie, and in that case the side effect is pushed to the edge of the system, when the response is sent.

Alright, true, yeah, there are side effects, was assuming that function worked on a different way (by doing something like leaving the response to be sent in the end of the plug pipeline). You are totally right, sorry for all the confusion, if the response was not sent on the redirect, there would actually be no reason to block people from setting the flash after calling it. Thanks for all the talk and sorry to take your time to explain that while I could figure it out by myself just digging a little on Plug’s and Phoenix’s code.

Think of the BEAM as a big Algebraic Effect engine in Haskell. The only ‘mutation’ goes through algebraic effects that the BEAM calls message passing. Everything within a process is entirely immutable, including the message passing, but it’s the ‘effect’ of passing messages between processes that causes the mutation in the overall world. The BEAM is pretty easy to reason about as a haskeller when thought of like that (because that’s what it really is).

I was about to write all these to you, but peerreynders wrote it much better than I could. Let me explain why I was confused. The main issue here is that most of the functions take the Plug.Conn struct as an input and generates a new (slightly different) version of it as an output; there was no side-effect, not even in the put_session function. However, the redirect function was different. It had side effects - that is, sending the response to the user through the server. I was too blind to side-effects, assumed that a functional language would at least try to avoid it until the very edge. I thought the side-effects would be declared through the Plug.Conn struct, but only invoked after it is returned.

Should have checked the docs before I started this thread, but it’s nice to see people discuss about this and explain the situation to me. Really liked Elixir and Phoenix’s community, you guys are great!

Not how functional algebraic effect systems work, the ‘effects’ happen immediately and the structures stay fully immutably functional.

With algebraic effect type systems you can even get fake mutation-looking variables that are still entirely immutable. ^.^