Problem/Motivation

When you load a new page, the sidebar opens every time. Even though it's fast, it creates a flickering behavior.

Proposed resolution

We can come up with a way to keep the state opened or closed based on the used interaction in the future, but for now for the prototype we can define that the default state is opened.

Issue fork navigation-3375855

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

ckrina created an issue. See original summary.

claireristow’s picture

Hey @ckrina, do you mean that we should have the default state be closed for now?

If so, I tackled this in a separate issue (now on the 1.x branch) so I think we can close this one?

ckrina’s picture

No, the default should be opened for now. When you access a page, we should assume the sidebar will be opened, not collapsed. In the future we should come up with a way that doesn't cause any flickering and respects whatever was the last state. But since this will be complicated for the initial implementation of the prototype and we need to choose either opened or closed for now, the default should be opened.

mherchel’s picture

During the meeting today, we talked with Sascha from Gin. They handle this using a combination of localStorage and JS that isn't dependent on DrupalBehaviors. We can go this route.

claireristow’s picture

Assigned: Unassigned » claireristow

Cool, I'll start working on this! I'll revert back to a default open state and use localStorage outside of behaviours.

claireristow’s picture

Hey @mherchel or @ckrina, I'm looking for some guidance on this one. I've added drupal behaviours, moved the initial localStorage check outside of the behaviours and I'm still seeing the flash. Any suggestions?

claireristow’s picture

Status: Active » Needs work
mherchel’s picture

OK. I played around with this a bit, and there are a couple things:

  1. We need to make sure we disable the width transition until everything is loaded.
  2. Even when we do that, we still get jank
  3. We can minimize the jank by splitting the following into its own JS file and library and loading it immediately, however there's still slight jank. And my guess is that it will be worse when aggregation is enabled and this file is combined with others.
    if (localStorage.getItem('sidebarState') === 'expanded') {
        document.documentElement.classList.add('navigation-active');
      }
  4. We can totally remove the jank by adding the following to the bottom of the navigation.html.twig template
    <script>
        if (localStorage.getItem('sidebarState') === 'expanded') {
          document.documentElement.classList.add('navigation-active');
        }
      </script>
      

    However, not sure how the framework managers feel about this

mherchel’s picture

Doing a little bit of research and I see that some inline JS was added to remove the current toolbar's flickering, so I'm guessing this is OK, but I'd still like to get a +1.

See #2998451: Toolbar tray rendering can result "flickering" resizing of content area to accommodate open trays

lauriii’s picture

Inline JS is not ideal but we couldn't come up with anything better in #2998451: Toolbar tray rendering can result "flickering" resizing of content area to accommodate open trays 🤷‍♂️ Given that it's a pre-existing approach for the toolbar, I think we can assume this will be accepted in core.

ckrina’s picture

+1 to what @lauriii said.

bnjmnm’s picture

The inline JS approach seems like the best (though we acknowledged not ideal) one. It was discovered after its implementation that comments within that JS do not work well in some aggregation scenarios, so be sure to avoid that in your solution.

claireristow’s picture

Status: Needs work » Active

Thanks for all the input everyone! I'll go with the inline JS.

  • claireristow committed 21278d05 on 1.x
    Issue #3375855: Avoid sidebar flickering when loading the page
    
claireristow’s picture

Assigned: claireristow » Unassigned
Status: Active » Fixed

Merged!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.