Views and templates

Requirement: This guide expects that you have gone through the introductory guides and got a Phoenix application up and running.

Requirement: This guide expects that you have gone through the Request life-cycle guide.

Phoenix views main job is to render the body of the responses to be sent back to browsers and API clients. Most of the time, we use templates to build said responses, but we can also craft them by hand. We will learn how.

Rendering Templates

Phoenix assumes a strong naming convention from controllers to views to the templates they render. The PageController requires a PageView to render templates in the lib/hello_web/templates/page directory. While all of these can be customizable (see Phoenix.View and Phoenix.Template for more information), we recommend users stick with Phoenix' convention.

A newly generated Phoenix application has three view modules - ErrorView, LayoutView, and PageView - which are all in the, lib/hello_web/views directory.

Let's take a quick look at the LayoutView.

defmodule HelloWeb.LayoutView do
  use HelloWeb, :view
end

That's simple enough. There's only one line, use HelloWeb, :view. This line calls the view/0 function we just saw above. Besides allowing us to change our template root, view/0 exercises the __using__ macro in the Phoenix.View module. It also handles any module imports or aliases our application's view modules might need.

All of the imports and aliases we make in our view will also be available in our templates. That's because templates are effectively compiled into functions inside their respective views. For example, if you define a function in your view, you will be able to invoke it directly from the template. Let's see this in practice.

Open up our application layout template, lib/hello_web/templates/layout/app.html.eex, and change this line,

<title>Hello · Phoenix Framework</title>

to call a title/0 function, like this.

<title><%= title() %></title>

Now let's add a title/0 function to our LayoutView.

defmodule HelloWeb.LayoutView do
  use HelloWeb, :view

  def title() do
    "Awesome New Title!"
  end
end

When we reload our home page, we should see our new title. Since templates are compiled inside the view, we could invoke the view function simply as title(), otherwise we would have to type HelloWeb.LayoutView.title().

As you may recall, Elixir templates use Embedded Elixir, known as EEx. We use <%= expression %> to execute Elixir expressions. The result of the expression is interpolated into the template. You can use pretty much any Elixir expression. For example, in order to have conditionals:

<%= if some_condition? do %>
  <p>Some condition is true for user: <%= @user.name %></p>
<% else %>
  <p>Some condition is false for user: <%= @user.name %></p>
<% end %>

or even loops:

<table>
  <tr>
    <th>Number</th>
    <th>Power</th>
  </tr>
<%= for number <- 1..10 do %>
  <tr>
    <td><%= number %></td>
    <td><%= number * number %></td>
  </tr>
<% end %>
</table>

At the end of the day, our templates are always compiled into Elixir code. Let's learn more about this.

Understanding template compilation

When a template is compiled into a view, it is simply compiled as a render function that expects two arguments: the template name and the assigns.

You can prove this by temporarily adding this function clause to your PageView module in lib/hello_web/views/page_view.ex.

defmodule HelloWeb.PageView do
  use HelloWeb, :view

  def render("index.html", assigns) do
    "rendering with assigns #{inspect Map.keys(assigns)}"
  end
end

Now if you fire up the server with mix phx.server and visit http://localhost:4000, you should see the following text below your layout header instead of the main template page:

rendering with assigns [:conn, :view_module, :view_template]

By defining our own clause in render, it takes higher priority than the template, but the template is still there, which you can verify by simply removing the newly added clause.

Pretty neat, right? At compile-time, Phoenix precompiles all *.html.eex templates and turns them into render/2 function clauses on their respective view modules. At runtime, all templates are already loaded in memory. There's no disk reads, complex file caching, or template engine computation involved.

Manually rendering templates

So far, Phoenix has taken care of putting everything in place and rendering views for us. However, we can also render views directly.

Let's create a new template to play around with, lib/hello_web/templates/page/test.html.eex:

This is the message: <%= @message %>

This doesn't correspond to any action in our controller, which is fine. We'll exercise it in an iex session. At the root of our project, we can run iex -S mix, and then explicitly render our template.

iex(1)> Phoenix.View.render(HelloWeb.PageView, "test.html", message: "Hello from IEx!")
{:safe, ["This is the message: ", "Hello from IEx!"]}

As we can see, we're calling render/3 with the individual view responsible for our test template, the name of our test template, and an empty map representing any assigns we might have wanted to pass in. The return value is a tuple beginning with the atom :safe and the resultant io list of the interpolated template. "Safe" here means that Phoenix has escaped the contents of our rendered template to avoid XSS injection attacks.

Let's test out the HTML escaping, just for fun:

iex(2)> Phoenix.View.render(HelloWeb.PageView, "test.html", message: "<script>badThings();</script>")
{:safe, ["This is the message: ", "&lt;script&gt;badThings();&lt;/script&gt;"]}

If we need only the rendered string, without the whole tuple, we can use render_to_string/3.

iex(5)> Phoenix.View.render_to_string(HelloWeb.PageView, "test.html", message: "Hello from IEx!")
"This is the message: Hello from IEx!"

Now that we have acquainted ourselves with Phoenix.View.render/3, we are ready to share views and templates from inside other views and templates.

For example, if you want to render the "test.html" template from inside our layout, you can invoke render/3 directly from the layout:

<%= Phoenix.View.render(HelloWeb.PageView, "test.html", message: "Hello from layout!") %>

If you visit the Welcome page, you should see the message from the layout.

Since Phoenix.View is automatically imported into our templates, we could even skip the Phoenix.View module name and simply invoke render(...) directly:

<%= render(HelloWeb.PageView, "test.html", message: "Hello from layout!") %>

If you want to render a template within the same view, you can skip the view name, and simply call render("test.html", message: "Hello from sibling template!") instead. For example, open up lib/hello_web/templates/page/index.html.eex and add this at the top:

<%= render("test.html", message: "Hello from sibling template!") %>

Now if you visit the Welcome page, you see the template results also shown.

Layouts

Layouts are just templates. They have a view, just like other templates. In a newly generated app, this is lib/hello_web/views/layout_view.ex. You may be wondering how the string resulting from a rendered view ends up inside a layout. That's a great question! If we look at lib/hello_web/templates/layout/app.html.eex, just about in the middle of the <body>, we will see this.

<%= @inner_content %>

In other words, the inner template is placed in the @inner_content assign. You can also find which module and template where used to render the inner content by introspecting the @view_module and @view_template assigns.

Rendering JSON

The view's job is not only to render HTML templates. Views are about data presentation. Given a bag of data, the view's purpose is to present that in a meaningful way given some format, be it HTML, JSON, CSV, or others. Many web apps today return JSON to remote clients, and Phoenix Views are great for JSON rendering.

Phoenix uses Jason to encode JSON, so all we need to do in our views is format the data we'd like to respond with as a list or a map, and Phoenix will do the rest.

While it is possible to respond with JSON back directly from the controller and skip the view, Phoenix Views provide a much more structured approach for doing so. Let's take our PageController, and see what it might look like when we respond with some static page maps as JSON, instead of HTML.

defmodule HelloWeb.PageController do
  use HelloWeb, :controller

  def show(conn, _params) do
    page = %{title: "foo"}

    render(conn, "show.json", page: page)
  end

  def index(conn, _params) do
    pages = [%{title: "foo"}, %{title: "bar"}]

    render(conn, "index.json", pages: pages)
  end
end

Here, we have our show/2 and index/2 actions returning static page data. Instead of passing in "show.html" to render/3 as the template name, we pass "show.json". This way, we can have views that are responsible for rendering HTML as well as JSON by pattern matching on different file types.

defmodule HelloWeb.PageView do
  use HelloWeb, :view

  def render("index.json", %{pages: pages}) do
    %{data: render_many(pages, HelloWeb.PageView, "page.json")}
  end

  def render("show.json", %{page: page}) do
    %{data: render_one(page, HelloWeb.PageView, "page.json")}
  end

  def render("page.json", %{page: page}) do
    %{title: page.title}
  end
end

In the view we see our render/2 function pattern matching on "index.json", "show.json", and "page.json". The "index.json" and "show.json" are the ones requested directly from the controller. They also match on the assigns sent by the controller. "index.json" will respond with JSON like this:

{
  "data": [
    {
     "title": "foo"
    },
    {
     "title": "bar"
    },
 ]
}

And the render/2 matching "show.json":

{
  "data": {
    "title": "foo"
  }
}

This works because both "index.json" and "show.json" builds themselves on top of an internal "page.json" clause.

The render_many/3 function takes the data we want to respond with (pages), a view, and a string to pattern match on the render/2 function defined on view. It will map over each item in pages, and call PageView.render("page.json", %{page: page}). render_one/3 follows, the same signature, ultimately using the render/2 matching page.json to specify what each page looks like.

It's useful to build our views like this so they can be composable. Imagine a situation where our Page has a has_many relationship with Author, and depending on the request, we may want to send back author data with the page. We can easily accomplish this with a new render/2:

defmodule HelloWeb.PageView do
  use HelloWeb, :view
  alias HelloWeb.AuthorView

  def render("page_with_authors.json", %{page: page}) do
    %{title: page.title,
      authors: render_many(page.authors, AuthorView, "author.json")}
  end

  def render("page.json", %{page: page}) do
    %{title: page.title}
  end
end

The name used in assigns is determined from the view. For example the PageView will use %{page: page} and the AuthorView will use %{author: author}. This can be overridden with the as option. Let's assume that the author view uses %{writer: writer} instead of %{author: author}:

def render("page_with_authors.json", %{page: page}) do
  %{title: page.title,
    authors: render_many(page.authors, AuthorView, "author.json", as: :writer)}
end

Error pages

Phoenix has a view called the ErrorView which lives in lib/hello_web/views/error_view.ex. The purpose of the ErrorView is to handle errors in a general way, from one centralized location. Similar to the views we built in this guide, error views can return both HTML and JSON responses. See the Custom Error Pages How-To for more information.

← Previous Page Controllers

Next Page → Ecto