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

Phoenix Forum Questions / Help
, ,
1

CONTEXT
I have a custom scrollbar that I control with JavaScript. This code needs to be executed without too much delay, because otherwise the user will see the elements that make up the scrollbar jump into their positions. The user should, instead, see the elements at their proper positions immediately.

The page I use the scrollbar on is part of a multi-page live session. I use live navigation (both pathing and redirecting) within this live session.

PROBLEM
When I use a mounted hook the JS script loads too late. When I import the script into my app.js (the ESbuild entry point), it is quick enough, but it load on all pages, not just the ones with the scrollbar on it – resulting in errors in the browser since it cannot always find the elements the script is referring to. If I create an extra ESbuild entry point and add a <script defer src=.../> to the LiveView that uses the scrollbar, the js script does load and also fast enough, but it only loads when I directly visit the URL that points to a page/component that includes the scrollbar. When I use live navigation (which a user will often), it does not load.

QUESTION
Any advice on how to include path-dependent JS scripts into a project would be very welcome. It’s not really about making my JS reference work properly, because I know I can find a way to do it. It’s more about finding a way that is pleasant to work with and fault tolerant. For example, solving the problem by including an event listener in my app.js that listens for navigation to specific paths, to then load additional scripts, seems maybe not the best possible option.

Thank you once again.

2

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

1 Like
3

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
1 Like
4

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.

5

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 :stuck_out_tongue: )

6

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

7

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

8

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.

9

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())
10

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.

11

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?

12

I don’t think a new primitive would be helpful given the example code I showed. The issue with beforeMount is we have scenarios where the hook element isn’t in the DOM yet, such as navigation events. Your best bet is to use existing primitives.

1 Like