fix: load page with hash + multiple Portfolio widgets with images

rodrigoalcarazdelaosa commented 3 years ago

Describe the bug

I just want to know if what is shown in this video is expected. I have a widget_page with lots of widgets (many of them portfolio). If I'm in a page and click on a link that goes to an anchor (section) on the previous widget_page, the first thing that I see is the section, but then the page scrolls to the bottom and then back to the section, slowly. If I, however, go back with my browser from the first page (back to the section on the widget_page), I don't experience any weird scrolling.

prueba

To Reproduce

Just click here and you will see that the page initially loads at the right section (2º Bach Química) but then goes crazy to the bottom and back to the section. The source of that widget_page (and all the widgets) is here.

Expected behavior

Ideally I'd like to have a behavior like what I have when going back with my browser. Go directly to the section without any weird scrolling.

Technical details:

Link to your GitHub project: https://github.com/rodrigoalcarazdelaosa/rodrigoalcarazdelaosa.me
Wowchemy Version (from your go.mod): 3a03b72
Hugo Version (run hugo version): 0.78.2
Browser/OS: Safari 14.0.1/macOS 11.0.1
Wowchemy Template: Based on starter-academic.

rodrigoalcarazdelaosa commented 3 years ago

Related to this, I just updated this discussion to reflect an update for AnchorJS, although not sure if it has to do with it.

rodrigoalcarazdelaosa commented 3 years ago

Relevant part of the code that may be related to this: https://github.com/wowchemy/wowchemy-hugo-modules/blob/master/wowchemy/assets/js/wowchemy.js#L499

gcushen commented 3 years ago

The effect is quite noticeable in this case as you are using a lot of dynamic height elements on that page. The height of each Portfolio widget is dynamic and currently unknown until Isotope JS and the images are fully loaded. The height of the fixed navbar is also dynamic, changing based on the window size.

To calculate the offset to a section on a page which has dynamic height elements, we need to know the height of those dynamic elements, such as by letting them load before determining the offset and then scrolling to it. You can see the first result is not quite right and appears before the page has fully loaded as it doesn't account for the dynamic height of the navbar, then it corrects itself and shows the start of the section with the correct spacing above it.

In this case, the user experience might be improved in a number of ways:

Try to place less Portfolio widgets on the same page (i.e. breakdown the content over more widget pages), reduce the number of Portfolio items on any one page, or link to the widget page itself in the navbar rather than a specific section on a widget page which has Portfolio widgets
Hide the page contents until the dynamic elements are fully loaded
Investigate if the anchor scrolling logic can be improved in some way

I think there may have also been a discussion somewhere in the past discussing a similar case.

If anyone has an improvement, feel free to open a PR for review.

rodrigoalcarazdelaosa commented 3 years ago

Thanks @gcushen. Let me comment on your response:

To calculate the offset to a section on a page which has dynamic height elements, we need to know the height of those dynamic elements, such as by letting them load before determining the offset and then scrolling to it. You can see the first result is not quite right and appears before the page has fully loaded as it doesn't account for the dynamic height of the navbar, then it corrects itself and shows the start of the section with the correct spacing above it.

I'd actually be quite happy if the page initially loaded to that not-quite-right position before taking into account the navbar, and allowed me to interact with it (eventually correcting after fully loading all elements). That loading of that initial (wrong) position is almost instantaneous. The problem is the scrolling afterwards and the fact that the page is unresponsive until it's fully loaded (it'd be great if the rest of the page could be loaded in the background but allowing interacting with the section loaded). Just a note: if I instead load the page without any anchors (https://rodrigoalcarazdelaosa.me/recursos-fisica-quimica/) loading is almost instantaneous and I can scroll down the page perfectly without all the page being fully loaded.

Try to place less Portfolio widgets on the same page (i.e. breakdown the content over more widget pages), reduce the number of Portfolio items on any one page, or link to the widget page itself in the navbar rather than a specific section on a widget page which has Portfolio widgets

This would be a perfect solution for me if widget_pages could be nested, this is, having folders inside folders. For the case we're discussing here, I'd be very happy if I could create folders inside my widget_page and then make those folders widget_pages too (with the corresponding index.md with type: "widget_page" in its front matter), in order to have widgets there too. Do you think this may be possible in a future update?

I think there may have also been a discussion somewhere in the past discussing a similar case.

I think you're referring to this closed issue #1643, right?

If anyone has an improvement, feel free to open a PR for review.

I'll keep an eye on this issue as I'm really interested on any improvement.

rodrigoalcarazdelaosa commented 3 years ago

Investigate if the anchor scrolling logic can be improved in some way

There's definitely room for improvement here. If I access this page (source here) without any anchor, it loads very fast and I can start scrolling (interacting with the page) immediately. If I, however, access a section of it, even if that section is almost at the beginning of the page, such as this one (source here), the page is unresponsive (I cannot scroll, or click any link) until it loads completely.

This may be the key

Also, if I access a section of the page once I'm in the page (clicking on any of the buttons such as the Graduation Cap Emoji 🎓), that weird issue with the scrolling does not happen, even if the page has not had time for loading completely (I just tested this clearing my cache).

Does this give any clues? When directly loading a section of a page, we just need to mimic what happens when accessing the page itself (without any anchor), and then (once we're in) getting to the section. That way the access is much faster.

rodrigoalcarazdelaosa commented 3 years ago

The effect is quite noticeable in this case as you are using a lot of dynamic height elements on that page. The height of each Portfolio widget is dynamic and currently unknown until Isotope JS and the images are fully loaded. The height of the fixed navbar is also dynamic, changing based on the window size.

This note:

// Note: If there are multiple project widgets on a page, ideally only perform this once after images
// from *all* project widgets have finished loading.

suggests that scrolling to anchor should be performed once all images have finished loading but I guess it's not currently implemented like that, right? That's the reason I initially see the correct section, but then the page scrolls to bottom and back again (it should wait until all images are loaded).

rodrigoalcarazdelaosa commented 3 years ago

The effect is quite noticeable in this case as you are using a lot of dynamic height elements on that page. The height of each Portfolio widget is dynamic and currently unknown until Isotope JS and the images are fully loaded. The height of the fixed navbar is also dynamic, changing based on the window size.

This note:
// Note: If there are multiple project widgets on a page, ideally only perform this once after images
// from *all* project widgets have finished loading.
suggests that scrolling to anchor should be performed once all images have finished loading but I guess it's not currently implemented like that, right? That's the reason I initially see the correct section, but then the page scrolls to bottom and back again (it should wait until all images are loaded).

Scrolling to anchor after all images have been loaded definitely improves the situation. This can be easily achieved by first running the code to filter projects and then scrolling to anchor, checking if all images have been loaded (see here):

if (window.location.hash) {
  $(document).imagesLoaded( function() {
    scrollToAnchor();   
  });
}

I still don't see why, with this code, the first loading of the page goes to the section, but then (I guess after all the images have been loaded) it scrolls again (maybe has to do with this?). My website already has this revised code running.

HugoBlox / hugo-blox-builder