Hash not removed when all accordions closed

[jeremy-farrance]

I put an Accordion at the top of the page with two expandos; Introduction and Reminders. Both default to not expanded. When you expand either, the hash is added to the URL... e.g. /pagepath#4461

Below this I have a few dozen rows of data that gets edited in the normal 2sxc way. The problem is when you edit one of your content items and save, the page refresh and - using the #hash - reopens the accordion and scrolls the page up and down to a different location than where you were editing.

Even with both accordion items closed, anything triggering a refresh causes the page to get hijacked and you can't stop it and its very confusing to the user. Normally after an edit/save, you expect the page to just update the data you changed so you get reassuring confirmation that your edits were made and saved.

Anyhow, is this something that needs to be fixed? Or is there a workaround? Or have I missed some setting or some part of the setup?

It seems like the accordion's JS should not only add the #hash, but also remove it. But it does not. So any page refresh causes unwanted scrolling and repositioning as well as an unexpected accordion item to reopen even though they were all left closed.

I made a GIF demo here.

[iJungleboy]

This does sound like a minor bug we should fix. @ropalko could you verify/fix this?

[iJungleboy]

Hi @jeremy-farrance

We're having difficulties formulating a good solution which matches all needs. The core concept behind the hash is that if people open a section they can then send someone a link which will go to that section and open it. That functionality is essential and must remain.

The editing issue seems much more complex after reviewing it, as there are many possible use cases, and each fix hurts a different use case.

Some use cases

1. A user may have opened a few accordions and is editing content inside one (latest or not)
2. The user may have opened some, but is editing content in a opened-by-default
3. The user may have opened some and is editing content outside of the accordion

In all these cases various reloads will happen, but there is no clear answer as to what should be in the URL and what not, to ensure the expected behavior. So basically it looks like it's a lot of work and no solution will be really good.

[jeremy-farrance]

Okay, so it seems the #hash is not the right way to store the state of each expando. Especially since there could be many accordion items and multiple might be open when a refresh is triggered and the #hash (as is now) only tracks one at a time. Use a different mechanism that does not create all these no win scenarios and manage things so the UI just works as expected. The real problem is that the #hash on the client side requires JS and you have animations that scroll/expand/collapse that have conflicting purposes with no control over if or when (or what order) they happen. Instead, manage it on the backend so that the front end has a clean set of starting conditions. Maybe data-attributes?

[iJungleboy]

That wouldn't work either - as the backend is just a razor template and doesn't know about expanded or not either.

An option would be to not use a hash when logged in as admin, but then the admin can't just send links to open sections - which is probably very common.

So basically removing the hash prevents the admin from creating share-links, no matter how we would otherwise handle the state. And as long as the hash is there, the screen will probably scroll... or is scrolling not an issue?

Note that of course the admin could have a js-cookie overriding the hash for open/closed state, but this all takes a while to develop. Since it's not a priority for us, we would need someone (like you 😉) to contribute the changes.

[jeremy-farrance]

Understood, thank you for the discussion!