feat: support mobile history back button

[lukeromanowicz]

Description

Resolves #337

I agree with @janmichek that this task ended up being quite a challenge. I managed to more or less get the expected result but it isn't perfect.

Demo

2023-08-30.12-19-26.mp4

Checklist:

• I have read and followed the Contributing Guide
• My change does not require a change to the documentation.

[github-actions]

Deployed to https://pr-475-aescan.stg.aepps.com

[CharisSiarampalis]

@lukeromanowicz The navigation is open when going back to the previous page. Shouldn't it be close so that the user doesn't have to scroll down?

[lukeromanowicz]

This is a good question. IMO if we consider the menu to be vital part of the navigation that should be supporting navigation through history button that I would say yes - it should show up when using the history buttons. Otherwise it would be incosistent

[janmichek]

firefox_Puc6i2s3to.mp4

I think the menu should not open when going back. It should only close when going back.
Even tho it's not very logical, as a user I don't expect opening menu again when navigating back

[lukeromanowicz]

@CharisSiarampalis @janmichek new version was rolled out and I think it's now working accordingly to the expectations you stated. Let me know if it's good

[janmichek]

Bigup! 🎖️ nice solution, readable and not that much code!

I only found one missing case:

1. go to dashboard
2. open navigation
3. click browser back
4. you will be redirected to previous page (navigation is not just closed)

[janmichek]

Suggested change

	{ 'header__container--open': isNavigationDrawerOpen },
	{ 'header__container--open': isNavigationOpen },

I think we can stick to original naming, or is there some consideration for renaming?

[lukeromanowicz]

I used NavigationDrawer just because I find it more specific and precise. Navigation is ambiguous since it may refer to bottom navigation or top navigation. Moreover, navigation on desktop is visible all the time, only the drawer is something that can be opened or closed. If this doesn't convince you I'll go back to the previous name

[janmichek]

I don't see a need for renaming as nothing has fundamentally changed, but if you insist on something more precise, you can use isMenuOpen. Just wanted to avoid introducing new names to codebase

[lukeromanowicz]

Great suggestion, I renamed it to isMobileMenuOpen

[janmichek]

Bigup! 🎖️ nice solution, readable and not that much code!

I only found one missing case:

1. go to dashboard

2. open navigation

3. click browser back

4. you will be redirected to previous page (navigation is not just closed)

Can you somehow imitate and pass fake history event when the navigation is open for the first time?

[lukeromanowicz]

Yes, that's the only idea I got so far

[lukeromanowicz]

I proposed a new version that adds "#navigation-open" hash if the page was visited for the first time to get rid of scenario that Jan mentioned. The drawback is that in this very specific scenario:

• open new tab and visit aescan
• open menu
• click any of the links
• click back button twice

to go forward you will also need to press forward button twice, since the hash stays in the history. Router history does not support detecting how much history is available ahead of the user and implementing this behavior would require at least a couple of additional hours of work and testing. I'm not even sure if it's possible to implement 100% reliably. I think the currently proposed version is the best balance of user experience to development effort.

[janmichek]

I proposed a new version that adds "#navigation-open" hash if the page was visited for the first time to get rid of scenario that Jan mentioned. The drawback is that in this very specific scenario:

* open new tab and visit aescan

* open menu

* click any of the links

* click back button twice

to go forward you will also need to press forward button twice, since the hash stays in the history. Router history does not support detecting how much history is available ahead of the user and implementing this behavior would require at least a couple of additional hours of work and testing. I'm not even sure if it's possible to implement 100% reliably. I think the currently proposed version is the best balance of user experience to development effort.

Ok, thanks for the new solution. I would say the previous one was a one star better than this one .) What you think?

[lukeromanowicz]

@janmichek Personally, I think the latest approach is more consistent and better for the user than the previous one. It reduces big inconsistency in very particular scenario to very small issue in that scenario (the need to press the button twice and only in very very specific scenario that may not happen ever to anyone - let's be real, who navigates back and forth on mobile device using history buttons)

[janmichek]

@janmichek Personally, I think the latest approach is more consistent and better for the user than the previous one. It reduces big inconsistency in very particular scenario to very small issue in that scenario (the need to press the button twice and only in very very specific scenario that may not happen ever to anyone - let's be real, who navigates back and forth on mobile device using history buttons)

Ok good, let's see Michele opinion. Thansk for fixes

[janmichek]

Good job 🍰

[janmichek]

Build stopped working. Let's continue in here #828