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.
OK, so I managed to both finished the book and the library 
I added a way to load less functions using configuration
config :surface_boxicon,
icons: [
regular: ["calendar", "chvron-down"],
solid: ["hand", "file-md"],
logos: ["docker"]
]
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.
Since this thread was first published, I migrated my code from Surface to vanilla LiveView.
Here is a new package for everyone using heex files: Boxicons Heex
I think the API to use it, it’s pretty clever:
<Box.icons
type="regular"
name="calendar"
size="64"
class="icon green"
/>
Have a nice day!
PS: It’s updated to use boxicons 2.1.1