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.
- Write a blog post how it’s done with primitives
- Write a helper lib/files requiring manual changes in Javascript files.
- Write a lib which solely relies on Phoenix so it’s a ‘add to mix dep’ and go.
- 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 
