Dev-only routes

To quickly test changes to email template copy and styling, I created a couple routes that are only accessible in the dev environment:

if Mix.env() == :dev do
  get("/email_previews", EmailPreviewController, :index)
  get("/email_previews/:email", EmailPreviewController, :show)
end

However, this now means that there is a template file that references a path helper function that doesn’t exist in other environments:

<ul>
<%= for email <- @emails do %>
  <li><a href="<%= email_preview_path(@conn, :show, to_string(email)) %>"><%= email %></a></li>
<% end %>
</ul>

which prevents the app from compiling:

** (CompileError) lib/my_app_web/templates/email_preview/index.html.eex:9: undefined function email_preview_path/3

How can I get the app to compile?

Try wrapping the for loop in a if Mix.env() == :dev block.

You don’t want to do Mix.env calls at runtime. Does the email_preview_path exist in a view that only is needed in dev?

1 Like

Oh, right! I guess it’s different for routes because they’re compiled?

Right, the if Mix.env == :dev do call in the router happens at compile time because it’s in the module body.

2 Likes

Yes, it only exists in a template that’s needed in dev.

Simply don’t use the compiled path functions. Instead type them as strings and interpolate values.

You could use Mix.env == :dev at compile time:

<ul>
<%= if unquote(Mix.env() == :dev),
  do: for email <- @emails do %>
  <li><a href="<%= email_preview_path(@conn, :show, to_string(email)) %>"><%= email %></a></li>
<% end %>
</ul>

When one needs different modules to be compiled in different environments, it’d be better to explicitly define these module sets, instead of polluting the source code with conditionals.

For the modules to be available in :test only, the common approach is to create test/support folder, and modify your mix.exs in the following way:

  1. Create a private function like this:
defp elixirc_paths(:test), do: ["lib", "test/support"]
defp elixirc_paths(_), do: ["lib"]
  1. Modify your Mix.Project.project/0 callback to include the following key/value pair:
elixirc_paths: elixirc_paths(Mix.env())
  1. Put all the files containing modules needed only in test environment there.

That way all of them will be compiled in test and discarded in all other environments.

If you need some modules to exist in :prod only, declare compile paths appropriately.

5 Likes

I literally laughed out loud and then facepalmed after reading your suggestion. Thanks!

1 Like

I ended up going with the solution suggested by @andrejsm but I did give this a try out of curiosity and couldn’t get it to work. At first, I was getting a syntax error, so I switched to a multi-line if statement to see if that was the cause—that fixed the syntax error but resulted in the same compile error about the path function not being available.

1 Like

Yeah the if unquote(Mix.env() == :dev) probably isn’t going to work. Templates are ultimately compiled into the view modules, so if you did:

if Mix.env == :dev do
  defmodule MyAppWeb.SomeView do
   # etc
  end
end

Where MyAppWeb.SomeView is whatever view module is related to that template I believe that would work.

Ah, okay. Thanks for the explanation. I gave that a try just to see (and for anyone else that stumbles across this thread) and you’re right, that works! Good to know.

I might be reading the post wrong, but Swoosh has a section in the README dedicated specifically to testing.

Clarification: Swoosh is an Elixir library for sending emails, with numerous plugable adapters for specific services.

Yea, I’m using both the local and test adapter already but needed a way to quickly, visually preview any email without having to trigger the sending. But thank you!

But Swoosh can do that. You don’t need to send anything. You can preview your emails in the browser.

Right, yes. I am already using that feature of Swoosh. However, I wanted a slightly different solution where I could quickly preview any email without having to manually go through the user flows within my application (e.g. filling out forms). Unless, I’m completely missing something in the README…

What I created, allows me to visit http://localhost:4000/email_previews and see a list of links to preview all my apps emails:

  • appointment_booked_patient
  • appointment_booked_practice
  • confirmation
  • duplicate_locations
  • new_app_version
  • password
  • unlock
  • user_registered_admin
  • welcome
  • etc

I also created a gist for anyone else who might stumble across this thread and want the same:

1 Like