Here’s some rough design ideas:

Let there be a special assign @favicon_href

The live_favicon_tag would go into layout/root_live.html.heex

<%= live_favicon_tag assigns[:favicon_href] || "/images/favicon.ico" %>

The live_favicon_tag function would emit the following HTML

<link id="phx-favicon" rel="icon" type="image/x-icon" href="/images/favicon.ico"/>

Add an event listener to the client javascript

window.addEventListener("phx:change-favicon", (e) => {
  var href = e.detail.href 
  var fabtag = document.getElementById('phx-favicon') 
  fabtag.href = href
})

On the server, when the LiveView process detects that @favicon_href has changed, push an event to the client:

push_event(socket, "change-favicon", %{href: @favicon_href})}

With this approach, add-on packages (like live_dashboard) could add their own favicon images to priv/images, and then use their own favicons in their particular LiveViews.

It’s gonna be 3 I guess.

Took some time to explore the problem domain a little further. As a result, I will create multiple libs all targeted at manipulating the static head.

Phoenix Live Head
Low level lib which includes functions to manipulate the head of the page incl. generic Javascript. It also takes care of minimizing data over the wire. The other libs depend on it, direct usage will be discouraged.

Phoenix Live Favicon
Lib which supports dynamic favicons! It will include a helper function to cover some exotic use cases, but will mainly be used with the HTML link element(s).

Phoenix Live Metadata
This one is a convenience lib which can be used pre-production (on production it is harmful!). It updates the metadata in the head for easy inspection.

Phoenix Live -other head element-

—-

This way devs can pick the parts they need for each environment.

Just to keep everyone informed

To be super clear
I fully understand and respect Chris’ rejection. He just doesn’t want anyone spilling time so he was quick to respond.

The rejection
The rejection was based on the commit and example code published.

The PR did not yet include support for multi favicon links nor some other features, as it was not final code yet. I used a ‘draft PR’ which GitHub says “is meant for discussion, not review” just to make sure the ‘we are working on this idea already’ would be represented at GitHub too and discussion about code could take place there.

So Chris was right the published code at that time could be done with 10 lines of primitives and -based on that- changing Phoenix codebase should not happen.

Future
Currently I see 4 options.

1. Write a blog post how it’s done with primitives
2. Write a helper lib/files requiring manual changes in Javascript files.
3. Write a lib which solely relies on Phoenix so it’s a ‘add to mix dep’ and go.
4. Challenge the rejection with the improved ‘include in Phoenix Liveview’ code and description why Chris’ solution won’t work (enough)

When option 3 is viable, it’s probably gonna be 3.

While the code for 4 is ready for a challenge, the challenge won’t happen until the pro’s and cons of all the options are clear and comparable.

So far
So far I have the code for 2 and 4 (they share most lines). Will make an attempt at 3 this weekend, should be quite straight forward.

One way or another we will have dynamic multi-link favicons in our Phoenix Live View apps; so just subscribe to this topic, wait and relax