Preserve settings page tab state on refresh and back/forward page navigation

[MareStare]

See the demo below

derpibooru-settings-tabs-demo-compressed.mp4

[uis246]

Why?
First of all: "Preserve ... state on ... back/forward page navigation" is already part of bf-cache system in browsers.
Second: Why do you change query string at all? You are changing document location. Document fragment exists for decades.
Third: How did fetchHtml did get there?

[MareStare]

Why?

The video in the PR description shows that current back and forward navigation on the settings page doesn't preserve navigation through tabs, page refresh navigates you to the first tab, and you can't create a deep link to a specific tab of the settings.

Why do you change query string at all

The HTML for the web page is generated server-side and it needs to know which tab to display on page load. URL # anchor syntax isn't sent to the server by the browser, so instead I'm using query params

How did fetchHtml did get there?

It was already part of the tab navigation code, I didn't modify it, merely moved some code lines

[uis246]

It was already part of the tab navigation code, I didn't modify it, merely moved some code lines

Wow. This is really how it works already.

The HTML for the web page is generated server-side and it needs to know which tab to display on page load. URL # anchor syntax isn't sent to the server by the browser, so instead I'm using query params

I just checked, and no, tabs don't change without working js. Nor js does any fetches when switching tabs. IMO this has no reason to be done on server. The sensible way is either to restore based on anchor or history state(window.history.state).

Anyway, I think this is not needed. Back/forward navigation restore is already handled by browser, while reloading page is something users expect to reset it to initial state. Although history API seems to have different opinion and preserves window.history.state on reload.

[MareStare]

IMO this has no reason to be done on server

The reason I do this on server is to prevent the FOUC-style problem. To prevent rendering the wrong tab during the page load and render the correct tab immediately. With client side solution, the browser will attempt to render the default tab while JS is not loaded, and after that JS script will quickly update the active tab to the correct one according to the anchor of the URL.

I'm not sure anchors were intended to be used like this due to this problem. This problem doesn't happen when anchors are handled by the browser natively, instead of page's embedded JS which loads asynchronously with page rendering. Especially because classic anchors don't change the visual look of the page, and merely scroll to the desired section of the page according to how browser natively handles them.

If you want to say that a flash of wrong tab is not a problem, and we still need to switch this to using anchors, than this decision requires more people's opinions, because discarding this problem is not a no-brainer for me.

Btw, another case where query parameters work better is when there are multiple UI sections with tabs in them. I don't think we have a page on our UI that has multiple tabbed sections, but if we were to have one, we'd need to store separate states for both of them. URL params allow multiple key/values, while anchors are intended only for a single simple HTML id element.

reloading page is something users expect to reset it to initial state

What do you mean by "reset to initial state on refresh"? When I am on a specific tab in settings and I refresh the page, I expect the page to remain on that specific tab, and not jump to some other tab.