LiveView organized JavaScript interoperability

Phoenix Forum Chat / Discussions
,
1

As I found out that phx:update emitted JS event is nowhere documented,
I thought using the JS client hooks would probably the recommended way.

But if I start using the hooks for a lot of small things and different LiveViews,
the would get a very unorganized long list of hooks…

Isn’t there a good way how to organize hooks per views?

Source of my question: Displaying UTC DateTime in users browser TimeZone

2

I’ve been using liveview extensively on a reasonably large project over the last 4 months or so, and as it developed I ended up pulling in a few different client-side JS libraries for things like D’n’D list sorting, autocomplete in textareas, maps, etc. which ended requiring hooks for interop with liveview.

In the process of development I’ve come to two patterns:

Pattern A: I am doing it wrong. :wink: Sometimes I have found that I’ll be ‘fighting’ to get around liveview unnecessarily and where a hook seemed like a good solution, it was really easier to just let liveview do its thing. Hooks should really only be used when absolutely needed.

Pattern B: Registering hook functions based on triggers. I have a handful of components on the front end that need something to run when the page is first loaded, others when the specific component is mounted, others whenever they are updated, etc. I had started out making hooks for the various components, but realized that they were verrrrry repetitive and when making changes to the front end, I’d have to make subsequent changes to the hooks in app.js. So what I’ve done instead is create a few generic hooks, such as this one:

Hooks.Mounted = {
  mounted() {
    window.mounted_elements.forEach(({ id, fn }) => {
      if (this.el.id === id) {
        fn();
      }
    });
  }
};

and then in the page-specific JS (I have modified the root template to check for js and css files in the @assigns to include specific cs/jss for different pages), something like this:

window.mounted_elements.push({
  id: "entry_attachments_list",
  fn: setup_file_uploader_impl,
});

… and in the leex template file:

<%= _f = form_for :uploads, "/upload", [id: "entry_attachments_list", class: "dropzone needsclick", phx_hook: "Mounted", style: "border: 0;"] %>

This has let me have a small collection of common Hook patterns which dispatch to functions that are registered by the page JS.

Still, I use them sparingly, and only when I haven’t entered Pattern A :slight_smile:

Also, related, perhaps … I find myself using pushEvent/push_event on both the client and server side to get information flowing between front end libraries and the liveview backend: when a front-end lib triggers some event in JS, it can be forwarded on to the liveview over the websocket easily, and when the backend receives an update that needs to be reflected in a component managed by a front-end library it can send those to the front end using push_event which is easily hooked up to client-side js as they enter the front end as, well, events which listener functions can be added to.

3 Likes
3

Thanks a lot.

Probably I also need to fight against Pattern A.
I’m often thinking I should avoid the network round trip.

But Pattern B sound like a reasonable solution.
I definitely need to try it in that fashion.