Toggle classes with Phoenix.LiveView.JS

I came here to ask this just now trying to make an indicator transform 180 degrees and not disappear.

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

It looks like its not in master yet.

I’m using dispatch for now:

js = JS.dispatch(js, "icon:rotate-180", to: "#accordion")

window.addEventListener("icon:rotate-180", e => {
    e.target.classList.toggle("transform-rotate-180")
});

I have an updated solution that supports more complexity inspired by some code I found in LiveBeats

# app.js
const execJS = (selector, attr) => {
  # this executes rendered JS commands on an element
  document.querySelectorAll(selector).forEach(el => liveSocket.execJS(el, el.getAttribute(attr)))
}

window.addEventListener('phx:collapse', e => {
  const id = `#${e.target.id}`

  if (e.target.getAttribute('data-open') === 'true') {
    execJS(id, 'js-hide')
  } else {
    execJS(id, 'js-show')
  }
})

~H"""
<div
  id="my-accordian"
  data-open="false"
  phx-click={JS.dispatch("phx:collapse", to: "#my-accordian")}
  js-show={show()}
  js-hide={hide()}
>
...
</div>
"""

Is there a reason to not merge the PR? Seems like a really popular request and also something built in to JS/DOM with classList.toggle? Maybe it adds too much complexity? Is the PR bad?

Not sure, I just again came in search of this functionality again two days back so I checked the PR to see why it hadn’t gone forward – just appears abandoned.

The updated solution from begleynk worked like a charm for me though.

Crossposting suggested solution for future searchers:

def toggle_expanded(js \\ %JS{}) do
  js
  |> JS.remove_class(
    "expanded",
    to: "#outer-menu.expanded"
  )
  |> JS.add_class(
    "expanded",
    to: "#outer-menu:not(.expanded)"
  )
end

It adds the class if it does not exist on the element and removes it if it does.

More like forgotten by the LV core team I would say. AFAICS they didn’t provide any feedback apart from “we’re aware of this one, just wait”. A useful feature indeed that should be part of the core JS module IMO.

how does it work though? Superficially, it looks like it first removes the class and then adds it, so shouldn’t it always end up adding it? Aren’t the remove_class and add_class commands executed in order?

Technically, yes, but the psuedo class :not selector in the command:

Only adds the class to the #outer-menu element if it does not have .expanded in its class list

never used LV.JS, so most likely stupid question: why not just use LV to toggle the class?

If you’re asking why not use the LV server state to render the element with / without a certain class, it’s because there are some UI interactions that don’t require a round-trip to the server which (can) introduce a couple hundred ms delay. Things like user profile menus opening/closing should be instantaneous (from a UX perspective) and don’t require the LV to keep track of its open/closed state

I hope that helps and answers your question

I think it implies a kind of “DOM transaction”, probably the changes are applied to a shadow DOM, while the selectors are run against the document DOM? This lets you batch changes up and do tricks like as listed but might also catch you out if you don’t expect it.

See this fiddle, where clicking remove then add (what it “looks” like the LV.JS is doing) is effectively a no-op, which isn’t observed in LV.

That doesn’t explain why it works. The first operation removes the class if the element has it, the second one adds it if the element doesn’t have it. But after the first operation the element is guaranteed not to have the class, so the second operation should always be triggered, resulting in a no-op as @soup has pointed out.

My guess is that the magic is happening here, but I wasn’t able to figure out how exactly.