Phoenix macro to render template if it exists in module

Maybe this would help? Current file (module) path - #3 by wojtekmach

The documentation includes alternatives:

The function_exported? alternative is not working. __MODULE__.module_info(:exports) does not list :index

This is how I understand the suggested alternative, but no joy:

if function_exported?(__MODULE__, :index, 1) do
  render(__MODULE__, "index.html", assigns)
else
  render("default_index.html", assigns)
end

It’s not working because functions and templates are different things. Phoenix.Template does not create individual functions per template, so you cannot use function_exported? to check if a certain template is available. The documentation shows not only the function_exported? code, but also a function that’s being checked for. This seems to be in line with the push to more function components using heex.

Ah, that makes sense. Is there any way to check for template existence? Or is using the deprecated function my only option?

Alternatively, how would I switch from templates to function components?

Unfortunately those really aren’t alternatives for what the OP is encountering (or what I am in my apps). It’s an alternative for a much narrower use case.

I’m still looking for a better solution, but will share what I’ve got.

In my site, there’s an embedded VuePress site (for a book that’s only loosely tied to the rest of the site). VuePress generates HTML files that I convert into Elixir templates upon each build. As a result, the Phoenix app needs to be able to conditionally render templates if they’ve been built or redirect to a 404 if they haven’t.

Here’s what I’m doing it the relevant controller:

  def page(conn, %{"page" => pages}) do
    template = Enum.join(pages, "/")

    if page_exists?(template) do
      conn
      |> put_layout({CampsiteWeb.LayoutView, :book})
      |> render(template, title: template)
    else
      Logger.warn("missing_template: #{inspect template}")
      conn
      |> put_status(404)
      |> render("404.html", message: "Page not found")
    end
  end

  defp page_exists?(name) do
    prefix = case Application.get_env(:campsite, :mix_env) do
      :prod -> "../../builds/campsite/"
      _ -> ""
    end
    File.exists?(prefix <> "lib/campsite_web/templates/potion/#{name}.eex") ||
    File.exists?(prefix <> "lib/campsite_web/templates/potion/#{name}.heex") ||
    File.exists?(prefix <> "lib/campsite_web/templates/potion/#{name}.leex")
  end

Note that this solution depends on the existence of template files in a specific location! In my case that location is different in prod than it is in dev, so I’ve added a mix_env key to the Application environment.

It’s not an ideal solution but it works for this use case as well as for a couple of other CMS-type apps where users need to be able to add and remove templates in content directories without changing controller or router code.

This sounds like the place to improve; your current process uses the template files both as templates and as metadata about which templates are defined. What if it instead output both template files and some sort of compile-able metadata?

For instance, you could generate a file like (name is terrible, sorry):

defmodule TemplateExistence do
  def template_exists?("foo.html"), do: true
  ...
  def template_exists?(_), do: false
end

This way the metadata about which templates exist and the templates are both embedded into the compiled BEAM files, and the template files themselves aren’t needed post-compilation.

I should clarify. VuePress outputs HTML files. I “convert” those to Elixir templates by renaming the files from whatever.html to whatever.html.eex. That’s it, and it “just works”.

I’m not dynamically outputting defmodule, def or any Elixir syntax and doing so would be both a lot more effort and a source of potential bugs. It would move the process from a quick integration between my static site generator and a Phoenix app into a larger engineering project that I don’t currently have the resources for.

Your suggestion is very straightforward as far as generating a .ex Elixir file goes, but it’s also replicating the same information I can now reliably get (with my current deployment strategy) by looking at the filesystem.

If I couldn’t rely on the filesystem, then dynamically generating one or more .ex files might be the only way.