samgaw

SVGs & EEx Tags: Inlining from External File?

There are already a couple of helper packages on Github to manage inlining external SVG files into templates which is great from a readability point of view. However I’m guessing because of the way templates are evaluated, EEx tags treated as strings.

Taking the thoughtbot package as the base for a simple example, do something along the lines of:

def inline_svg(file_name) do
  path = static_path(file_name)
  case File.read(path) do
    {:ok, file} -> {:safe, file}
    {:error, _} -> raise "No SVG found at #{path}"
  end
end

defp static_path(file_name) do
  path = "assets/static/svg"
  [path, "#{file_name}.svg"] |> Path.join() |> Path.expand
end

That will render the SVG but include the EEx as strings rather than the output of <%= some_func() %> included in the SVG file as expected because of the {:ok, file} -> {:safe, file}. But removing that and going with {:ok, file} -> (file), or wrapping the svg_inline() function with raw() still doesn’t give me the desired outcome.

So I’m wondering where in Phoenix’s order should I be attempting to run this so that tags included in the inlined SVG are rendered as expected?

Thanks.

13 comments

/phoenix #eex #troubleshooting

1 3584 13

2020-01-27 15:18:54 UTC

First Post!

hauleth

As far as “pure” EEx is concerned there is absolute no difference, as raw EEx do not care about “tags”, as it do not understands them. If you are talking about Phoenix HTML, then code you have presented should work as expected. Are you sure that returned string is wrapped in tuple?

Post #1

Most Liked

LostKobrakai

Your problem is that you’re using a function here. The function will be called at runtime, but at runtime the svg’s won’t be available (when using releases) or at least the path might no longer match. You’d want to use a macro, so you read the svg’s content at compile time and only have the result inlined with all the other eex template contents.

Post #4

al2o3cr

I’m definitely missing something - the inline SVG macros above are designed to be used like:

    <button class="btn btn-primary mb2 btn-ple" style='margin-left: 5px' type='submit'>
      #{ Svg.inline("SquareOk") } 
    </button>

(from the code AndyL linked)

But if you’ve got EEx markup that needs to be compiled into a function to return the SVG, it seems like render with an .svg.eex partial should do the right thing:

  <div class="place-where-svg-goes">
    <%= render("my_template.svg", some_param: "foo") %>
  </div>

What about the render approach doesn’t work for your use case?

Post #12

hauleth

Your macro:

defmacro inline_svg(file_name) do
  path = static_path(file_name)
  case File.read(path) do
    {:ok, file} -> quote do: {:safe, unquote(file)}
    {:error, _} -> raise "No SVG found at #{path}"
  end
end

Post #6

Last Post!

samgaw

render works fine. It just gets a little unwieldy as the number of components increases and they start getting shared between views. Which is why I was saying I’ll maybe get a chance to revisit it at some stage to find a more elegant approach to structuring them in a project e.g. helper macros + a different pattern on use Phoenix.View, root: "".

Using the inline macros for styling elements genuinely wasn’t a use case I’d consider so it makes now why I was confused with responses here