What you propose is perfectly fine and it will work! You will lose some Surface features, like compilation checks, and properties documentations.
@fceruti you can follow what @miguels did with ExHeroicons by creating a Phoenix helper, boxicon("video-plus", type: "solid") for example, and Surface will “just” uses that helper. In that case, you will be able to use the icons both with Phoenix with and without Surface.
I’m about to finish this book, and it’s blowing my mind. Meta programming is
I’ll study this after nailing the compiling issues I’m facing. Thinking out loud here, I’d like the library to no have surface as dependency if you are not using it. Is that even possible? are there configurable dependencies?
–
Thanks to @kip and @josevalim for pointing out the way. I want to understand every line of code first, so I’m taking my time to study.
But it turned out to be completely unnecessary, the Module is compiling super fast with all the icons. The current Boxicon module looks like this:
defmodule Boxicon
...
def render(assigns) do
~F[<svg xmlns="http://www.w3.org/2000/svg" width={"#{@size}"} height={"#{@size}"} class={"#{@class}"} viewBox="0 0 24 24">{render_content(@type, @name)}</svg>]
end
for %Boxicon.Source{type: type, name: name, content: content} <- @icons do
defp render_content(unquote(Atom.to_string(type)), unquote(name)),
do: unquote(Phoenix.HTML.raw(content))
end
defp render_content(_, _), do: ""
end
I’m not sure why this is the case, but maybe the compiler is having an easier time dealing with string signatures instead of maps. If I create one render function per icon, pattern matching on the assigns map, I go back to lousy compile times.