LiveView generates its own HTML id attribute for the container. Something like:
id="phx-Fw6uOp26N8TUEwOI"
That’s all understandable as I may want to render multiple LiveView elements. But… The Fine Docs say:
- You can change the default
container on use Phoenix.LiveView:
use Phoenix.LiveView, container: {:tr, id: "foo-bar"}
It seems though that using this method I can in fact give the container an arbitrary class attribute but the id remains the generated one…
use Phoenix.LiveView, container: {:div, [class: "widgets-container", id: "widgets-container"]}
gives:
<div class="widgets-container phx-connected" data-phx-session="SF[…]FD9IEY" data-phx-static="SFMy[…]gsLXLY" id="phx-Fw6uOp26N8TUEwOI" data-phx-root-id="phx-Fw6uOp26N8TUEwOI">
What am I doing wrong?
SO version of the question:
It doesn’t sound like you’re doing anything wrong, LiveView just ignores the id you pass because it wants to use its own unique id.
Do you need to rely on the id? Generally speaking, using ids is a bit of an anti-pattern unless you’re working at the library level (like LiveView is) and managing nodes directly. If you’re just trying to select your node in JS or CSS, would a class or data attribute work just as well?
Technically I don’t have to rely on the id attribute. There are workarounds for the non-working id. Like those you mentioned for example. It simply is:
a) my old habit that whenever I know I am unique with the id, I use it before resorting to other options.
b) AFAIR it still remains the fastest selection method, including the most straightforward getElementById() JS
c) the docs give a clear example where I assume the generated id is expected to be overridden and I am unable to reproduce the docs-expected behaviour
I apologize, I missed this part. (On my phone and didn’t scroll horizontally far enough in the docs example.)
Consider opening a GH issue for clarification. It seems that one of the docs or implementation are incorrect. Either way, a bug 
