The code I’ve written to get around this issue (using the liveSocket to trigger JS commands in data- attributes) is some of my least favorite in my app - it’s obviously suboptimal. I think opening up the sticky API is inevitable, and I don’t see any obvious problems (it’s the same thing we’re already doing anyway, just directly). I would imagine the work simply hasn’t been done yet - JS commands are still relatively new and improving quickly. We only just got toggle_class, which was a big improvement 
garrison
2
sezaru
Yep, that’s what I do as-well, but as you said, it is not a great way to handle these cases and kinda hacky
1
steffend
Phoenix Core Team
@garrison already made some very good points. We don’t plan to make complex JS commands.
There are lots of improvements planned for hooks. One of them is to actually expose sticky JS commands like this:
mounted() {
const js = this.js();
// js.show, js.hide, js.transition, etc.
js.toggleClass(this.el, ...);
}
Another big improvement will be colocated hooks that will allow defining the necessary JavaScript next to the components themselves.
9
steffend
Phoenix Core Team
which API do you refer to? getBoundingClientRect? If that’s the case then no, we don’t work on it and we also wouldn’t want to expose this through Phoenix.LiveView.JS.
For the other stuff mentioned: the PR for sticky ops in hooks is here Extend client with createHook, js client commands, and lock/unlock support by chrismccord · Pull Request #3307 · phoenixframework/phoenix_live_view · GitHub. I don’t know what Chris is up to at the moment, but that’s the one to follow for that.
Concerning colocated hooks that’s probably something for after 1.0.
2