Multiple hooks in Phoenix?

Only one. You could write a generic one that delegates to others, or, if they are truly independent hooks, wrap your node in a <div> with your second hook.

Thanks for the info. What’s your take on a generic delegation? Are you thinking, for example, that if there was a need for pointerdown, pointerup, and pointermove listeners, you would have a ‘pointer’ hook that encompasses them all instead of individual hooks? If that’s the case I would end up with duplicates if I just wanted, say, a pointermove.

Those hooks sound entirely too granular to me. I would think of a hook like a component. The hook should capture all of the behavior of that component that needs to happen at the JS level. A given DOM element simply is only one component, it doesn’t make sense to be multiple. Composition would be accomplished by a component that can contain other components.

I understand when you say ‘think of a hook as a component’. But I can’t visualise what you mean by ‘contain other components’. Would you mind showing a super basic example?

I think telling us your use case might be best for guidance.

A hook isn’t just “a listener to pointerdown, pointerup, and pointermove”, you want to do something with those, right?

Well, I’m trying to think more generally to understand the best approach to using hooks. I’d like to work on JS-heavy features, such as implementing drag-and-drop or drawing with SVGs. However, I want to ensure the code is modular and reusable, similar to how I would structure it with vanilla JavaScript or a framework like Svelte.

For instance, in a drag-and-drop feature, I might have functions that process pointer events, retrieve the client X/Y coordinates, and transform that data into a specific unit. In Svelte, I would make these reusable functions since I might use them frequently across my codebase.

If I combine everything into a single component-style hook, I risk ending up with redundant or repeated code. So I’m looking for general advice on how I can best structure hooks to maintain modularity and reusability while avoiding code repetition

You may be confusing how to structure your JS side code into “libraries” (functions / classes / etc) and how to structure your hooks. Your hooks are the end-users of your libraries, not your libraries themselves.

I’d recommend to start with actual code and restructure later. You might get lost in remaining very abstract.

Good luck

That’s actually very helpful. Thank you

I was asking myself the same thing today.

As a use case, two existing hooks that made sense using in a single container: “size observer” and “chart renderer”.
The suggestions in previous answers are still viable:

• use multiple containers, one hook on each;
• using a single hook as a thin wrapper around common functionality implemented elsewhere.

But with LiveView 1.1, another possibility is using ColocatedHooks for one-of “composition”. Composing two existing hooks is probably too cumbersome, it’s probably a better idea to have the functionality separate from hooks, and hooks only call functions in reaction to lifecycle events (mount, update, destroy, etc).

Colocated or not, the “chart renderer” could also just use the functionality of the “size observer” so that we only need a single phx-hook attribute.

Right, I don’t think colocated hooks are exactly relevant here. The confusion is caused by thinking of hooks as units of abstraction, because they are not that, they are just javascript “controllers” for your DOM, which already defines the units of abstraction. They expose an API for triggering behavior on rendering events, not injecting specific logic.

I don’t think OP ever shared details about the original use case beyond “size observer“ and “chart renderer,” but presumably those would be modules that a single hook on a component that uses both features would import, either in app.js or in the component itself in the case of collocated hooks.

I am tempted to wonder whether forcing them to be component specific in some way would have made this clearer. Or, if allowing multiple hooks per component was really desirable, just having phx-mount/phx-update attribute, but then I don’t know how the more advanced features would work.