Just playing around with Phoenix.LiveView.JS and wondering if there is a way to toggle classes on and off on an element? There is ‘add_class’ and ‘remove_class’ but ‘toggle’ looks like it is just used for showing and hiding. But maybe there is a way but just can’t see it.
4 Likes
I came here to ask this just now trying to make an indicator transform 180 degrees and not disappear.
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")
});
5 Likes
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>
"""
2 Likes
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?
4 Likes
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.
2 Likes
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?
1 Like
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
1 Like
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.
1 Like
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.
The important thing to remember is that the JS commands are not executed at the time they’re invoked, they’re added to the JS struct as a sort of “batch” command – You can see here that add_class doesn’t actually add the class, but puts an “op” into the ops field of the JS struct as a command
So, when add_class is invoked, even though it comes after remove_class, the classes haven’t actually been removed from the element. That’s why the :not selector works
So at the end of the toggle_class fn above, the JS struct has two ops, 1 for removing classes, and 1 for adding classes, with the end-result being a toggle
I’m aware of that. But that’s only where the commands are stored in the page waiting to be executed by the javascript front end. The js front-end executes them here in sequence, so without special care the end result would be a noop (remove the class, the add the class). Something is happening at the JS level that prevents it, not in Elixir.
I see what you’re getting at.
So – Only thing I can think is that the class names are collected before any of the JS commands are executed.
I’m digging through the live_view.js to see the order of execution but haven’t gotten it 100% yet
A simple way to solve this by native html:
<button
onclick="document.getElementById('element-ie').classList.toggle('toggle-class')"
>
click
</click>
That wont survive dom patching, probably.
1 Like
