OK, here are the results (I little different than what I experienced before for some reason)
1 module version:
❯ time mix compile
Compiling 2 files (.ex)
Compiling lib/boxicon.ex (it's taking more than 10s)
Generated surface_boxicon app
mix compile 27.49s user 2.24s system 106% cpu 27.818 total
1527 modules version
❯ time mix compile
Compiling 1527 files (.ex)
Generated surface_boxicon app
mix compile 71.68s user 8.96s system 437% cpu 18.427 total
Looks great! Maybe you could make the included icons and types configurable. Then you can reduce the number of function heads to generate at compile time. Most projects would only be using a small subset.
Edit: didn’t look at the implementation first. I was assuming you were using a macro to generate the function heads at compile time.
This sounds neat! Can you point me to a project that does this? I’m still a n00b and talking about macros goes over my head at the moment.
No more of noob than me. I can’t think of a project off the top of my head. This (nice and short) book is a great way to learn more about macros though: Metaprogramming Elixir: Write Less Code, Get More Done (and Have Fun!) by Chris McCord
Hopefully someone with a bit more experience can point you in the right direction, or clarify if this is a good use case for macros at all!
You wouldn’t necessarily need to implement any macros, but meta programming would still be useful. Something like:
defmodule Boxicon do
@doc "Type of the icon"
prop type, :string, values!: ["solid", "regular", "logos"]
@doc "Name of the icon"
prop name, :string, required: true
@doc "Width & height of the icon"
prop size, :integer, default: 24
@doc "CSS classes for the wrapping svg element"
prop class, :string, default: "icon"
@icons "populate icons from static data at compile time"
for {type, name, path} <- @icons do
def render(%{name: unquote(name), type: unquote(type)} = assigns) do
~F[<svg xmlns="http://www.w3.org/2000/svg" width={"#{@size}"} height={"#{@size}"} class={"#{@class}"} viewBox="0 0 24 24"><path d=unquote(path)/></svg>]
end
end
end
Happy to help with how to structure the data to populate @icons at compile time if you need.
@fceruti here is a fork where I was playing with something along the lines of what @kip suggested. It’s definitely not complete (or probably the most idiomatic Elixir) but it might be helpful. GitHub - joshdcuneo/surface-boxicon: Surface component library that wraps the amazing boxicons library. · GitHub
The compile times were a lot faster when I just specified the “logos” type to be included so if you allowed configuring the included icons it should be pretty quick.
There seem to be categories as well as different cuts for boxicons, so there are already some bags to split into different modules by.
To build on top of @Kip’s, you can share the common parts and leave only the different bits for meta programming:
def render(assigns) do
~F[<svg xmlns="http://www.w3.org/2000/svg" width={"#{@size}"} height={"#{@size}"} class={"#{@class}"} viewBox="0 0 24 24"><path d={path(@name, @type)} /></svg>]
end
for {type, name, path} <- @icons do
defp path(unquote(name), unquote(type)), do: unquote(path)
end
I haven’t looked too deep but are there any Surface specific things in this library? I wonder if it would be more reusable to use Phoenix’s component & functional component API? (Reusable across non-Surface LiveView apps and normal non-LiveView Phoenix apps)
I’m thinking something like:
# usage
<%= component(&BoxIcon.bell/1, []) %>
# definition
defmodule BoxIcon do
def bell(assigns) do
~H[<svg>...</svg>]
end
end
Here’s some resource on the upcoming changes Surface and Phoenix LiveView - what comes next? - Dashbit Blog (it links to different PRs there as well)
Just a thought! No clue if it’d work at all
@edisonywh Yes and no 
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.