Checking param is present in phoenix controller function

Just getting familiar with Elixir & Phoenix and was hoping for some clarity and direction. First, is it a good habit to have multiple controller functions of the same name and just pattern match against certain params or lack of params? If so, how would I make something like this:

def show(conn, params) do
    conn
    |> assign(:message, params["m"])
    |> render(:show)
  end

  def show(conn, _params) do
    conn
    |> assign(:message, "there")
    |> render(:show)
  end

work? As in, how can I ensure a certain parameter (in this case for simplicity, just the parameter “m”) is present, and if not, skip over it to the next function that matches. Because at the moment, I could pass the parameter “?me=Mike” and it would match with the first function.

I realize that I can do something like:

def show(conn, %{"m" => messenger}) do
    conn
    |> assign(:message, messenger)
    |> render(:show)
  end

but am curious if it is possible to pattern match with just a def action(conn, params) variable instead (so that I can test against multiple params if need be).

I also realize most parameter based logic will be handled by Ecto.Schema, but want to know if this is possible.

Thanks for taking the time to help this newb! :smiley:

1 Like

You could match like so:

  def show(conn, %{"m" => messenger} = params) do
    # do something with params

    conn
    |> assign(:message, messenger)
    |> render(:show)
  end

or

  def show(conn, %{"m" => messenger, "other" => other}) do
    # do something with other

    conn
    |> assign(:message, messenger)
    |> render(:show)
  end

I believe a function head match error results in a 400, while a match error in the body results in a 500. So, if you want an accurate API response, it’s simpler to do all the matching of required params in the function head. Otherwise, you’ll want to be more conservative in the function body when checking params. Like you mentioned, another valid approach is to use a changeset.

2 Likes

This is perfect. Thanks very much for explaining that. I didn’t even consider the consequences of API error responses so thanks for giving me something to consider!