Feature Request: LiveView Dynamic Favicon

Here is a working prototype for Dynamic Favicon. A streamlined solution that follows the style of live_title_tag would be great. I will help.

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.

Awesome job @AndyL! I am not sure if this is such a common use case to warrant inclusion on LiveView, but that’s all the pieces needed for anyone who wants to roll with it.

It would be a great quick win!

Great example!

• Should it support a size opt (or list of sizes and return multiple elements)?
• SVG icons can be styled with CSS; removing the need for multiple images (in an ico container). Should it support that use case and if so, how? Blog post: Building an adaptive favicon

The other option is to keep is really simple and let a lib handle more advanced usecases

Didn’t know about SVG icons - super nice! Pretty well supported on desktop browsers, less on mobile. Also learned that people sometimes use multiple favicon links, to give browsers an way to fall back to supported types.

I think there are two alternatives to attack this problem: manual coding like I did in the prototype, or editing LiveView itself. I don’t think this can be done with a Library, because there is no way for a Library to inject behavior into the LiveView JS. Is this right?

I looked in the LiveView code to understand live_title_tag - there seems to be three key areas in the code:

• dom.js:138 - putTitle
• view.js:223 - applyDiff
• diff.ex:158 - maybe_put_title

The code itself looks pretty straightforward - with a good amount of testing support.

Generating the appropriate favicon mime type could be done by checking the file extension of the href - this could be done in the javascript.

size opt

I’m not sure what the size opt does - I’ve always used ‘auto’ size.

The other option is to keep is really simple

If we could do something simple to streamline the 80% case, people could always fall back to a manual approach if needed.

Chose to keep the assign key generic; not sure of we can pass components to it (its too late).

If we can the favicon_tag function can use the (to be updated) DOM diffing too as no attribute is in the name. This allow for the simple approach by default using it as href when assigned a binary. Keeping the advanced usage of favicons to a lib which can simply pass a full icon link element.

Too be continued….first let’s see if the draft PR survives the public exposure.

Schermafbeelding 2022-06-30 om 01.47.42828×322 26.3 KB

https://github.com/phoenixframework/phoenix_live_view/pull/2087

Won’t take long before you can play Doom in the browsers` tab bar…

PR looks great - beautiful screen shot!

I’m curious - did you intend that it should be possible to update multiple favicon links, or just one? If multiple: would you assign an array of hrefs to @favicon, or use some other convention?

Last night I looked at support for multiple icons

Phoenix LiveView is awesome at diffing and sending the least amount of data over the wire. I am trying to keep that in honor. As a result I have chosen to use a simple string replace.

The free schema also makes it easier to use online favicon generators that generate a bunch of PNG files for you. Just unzip and place in a subfolder of a variant. SVG scale so don’t need a subfolder. See pseudo code:

# pseudo code supports multiple schema’s
<.live_favicon href="/images/svg/@dynamic.svg" />
<.live_favicon href="/images/status/@dynamic/favicon-32x32.png" />
<.live_favicon href="/images/status/@dynamic/favicon-16x16.png" />

When a new @dynamic value is assigned, the href is split in 3 parts: prefix, @dynamic and suffix. The dynamic value is replaced with the value assigned.

static: /images/status/
dynamic: “new_message”
static: /favicon-32x32.png

Only the dynamic part is sent over the wire on socket assign updates. Just like…LiveView does already

{"f": {   "dynamic": "new_message"}}

When href is defined without a dynamic, the helper assumes the user needs full control over the href and just passes it through. Thus supporting base64 encoded data and one-off use cases.

This also allow me to add ‘class’ to support those fancy dynamic SVG’s.

As you like screenshots:

Schermafbeelding 2022-06-30 om 18.45.32714×271 30.5 KB

Update: the draft PR is rejected

Not sure if the presented solution really covers the use cases as mentioned above. It does cover the simple first case in the draft though, so it’s not a surprise. Will check later.