Yeah, that’s precisely why I decided to ask on the forum.

So I don’t have precise use case just yet, but I am evaluating alpine.js and how people are integrating it with Phoenix LiveView Hooks. The most comprehensive guide I found is here, and it’s full of ugly hacks. For example:

Hooks.Counter = {
  mounted() {
    window.counterHook = this
  },
  decrement() {
    this.pushEvent('decrement', {})
  },
  increment(selector) {
    this.pushEventTo(selector, 'increment', {})
  }
}

The above is how they turn the Hooks into something à la stimulous controllers, which I think is pretty neat. But the way they use global property on the window object is not great, and will quickly fall apart when you are about to render a list of Counters for example.

In the next section they send events from Alpine to Hooks, which is not great either as it goes through window instance and not the element in one way, and they are able to do it better when sending events from Hooks to Alpine.

I believe it would be both cleaner and less error-prone if we could, having a DOM element find instance of Hook that is, well, hooked to it. We can do the opposite quite easily.

The problem with the hacks I am seeing in that tutorial is that you need to do proper cleanup (which is not mentioned) in order to avoid double callbacks being installed, or memory leaks on the client in the browser if you leave unused callbacks set up on the window object, especially if those callbacks reference DOM nodes.

Having a two way integration would basically turn Hooks into Stimulous controllers on steroids.