Hooks load too slowly for use case: looking for a sensible alternative

You can have a placeholder where those elements will end up and fade the actual ones in when they load so it’s not so jarring? How big is this scrollbar JS that the load time is so significant?

There are several blogs on page specific JavaScript with liveview hooks and IIRC LiveBook does it too.

Here is one such blog: Page Specific Javascript with Phoenix LiveView and Esbuild · aswinmohan.me

This sounds like a variant of the “flash of unstyled content” issue, but with JS loading time as the issue instead of CSS loading time.

A similar solution to FOUC-prevention could work:

• set the elements to display: none (directly or with CSS) in the rendered HTML
• display those elements at the end of the mounted hook, maybe with a CSS transition

The scrollbar itself is computationally light. It’s the mounting of the LiveView that takes a bit of time. And since the mounted hook executes after that, the layout shift happens.

The initial paint (the first server request by the LiveView) of the page is fast. The second server request has the delay.

My idea was to have my scrollbar script execute between those two server requests. And that does work, but then the script does not load on live navigation – only on direct loading of the target url.

Edit: and I’ll have a (better) read of the link you sent.

I think this will work great for this specific use case. To keep the management of page specific JS simple (i.e. avoid it all together )

Would a beforeMounted hook be a nice addition to the current set of hooks ?

Can you elaborate on how that might work or when it would fire in the page lifecycle?

I hope to have the knowledge necessary to fully answer that question one day soon. For now I still have too much of my baby fur on me.

However, I can imagine there is an opportunity here:

On each mount LiveView establishes a web socket connection and replaces the initial paint. If there is a hook right before that, this would increase the control of developers.

This should suffice to handle both the immediate scrollbar on page ready, as well as after live navigations, without a hook in the mix:

Scrollbar = {
  init(){
    let el = doument.getElementById("scrollbar")
    if(!el || (this.el && this.el.isSameNode(el))){ return }
    this.el = el
    //...
  }
}
document.addEventListener("DOMContentLoaded", () => Scrollbar.init())
window.addEventListener("phx:page-loading-stop", info => Scrollbar.init())

An additional benefit of using hooks is that it can help with code organization. Using Surface UI I can colocate my hooks and my LiveView.

|
|__ example.ex
|
|__ example.sface
|
|__ example.hooks.js

For me that beats setting up additional entry points with ESbuild or referring to modules in app.js.

Quick update.

It still happens regularly that I wish I could access some non-existing life cycle hook. Before it was beforeMount, this time around I’m working on transitions and I was hoping for a beforeDestroy.

Would a pull request be excepted?