fix: adding legacy hash link support #2581
Conversation
| // Legacy link support: For the hash-based links dating before Jan 2025 when we transitioned to a multi-page site | ||
| // For example, redirects from /#menu-button-radio to /component/menu-button#menu-button-radio | ||
| document.addEventListener("DOMContentLoaded", function() { |
There was a problem hiding this comment.
Note: This waits for DOMContentLoaded so it can verify that the currently referenced #hash link doesn't already exist as a link to the current page (to prevent accidental redirects). Note that this code short circuits on component/guide pages anyway (see below); but this check is just to be safe. Of course, if we ran synchronously here, the DOM parser wouldn't have had time to load elements on the page so a query select would fail (thus the need to wait a little).
| return; | ||
| } | ||
| } while ((lastIndex = partialHash.lastIndexOf("-")) !== -1); |
There was a problem hiding this comment.
This was done instead of either blindly redirecting (very insecure) or packing the entire component link list (as an allow list). Instead, we'll just reference what's already on the page navigation using an educated guess (i.e. checking to see if a /component/HASH/ link is present).
It goes from longest to shortest to help match overlapping prefixes.
|
Btw, lmk if I'm too verbose in my JS comments; I can cull those down a little bit if you want. |
|
Thanks @patricknelson ! I'll take a closer look next week after our release. In my initial glance at it though, why not just update the old hashlinks in the html? Feels a bit of an over-engineering, but I'll take a closer look next week. |
This is to support external incoming links that have built up over the years (e.g. in Slack or saved in jira, documentation and etc) which are referencing the old Does that make sense @ArtBlue or did I misinterpret your question? Edit: p.s. The internal linking issues were already addressed in #2573 (described in #2570), where just within the Skin documentation, cross linking between components was broken. This addresses old links living everywhere else. 🙂 |
|
Also worth noting that, unfortunately, there's no way to fix all of those broken inbound links external to the site without client-side processing, since I could probably do a better job at the top of the |
patricknelson
force-pushed
the
fix-legacy-links
branch
from
e3f1e4e to
47ab108
Compare
|
Fixes legacy hash links and redirects to the correct component or guide page
Description
Ensures that links going to the legacy URLs such as the following are properly redirected. Example test cases:
#menu-button-radioredirects tocomponent/menu-button/#menu-button-radio(retains deep link)#menu-buttonredirects tocomponent/menu-button/(no trailing hash)#menuredirects tocomponents/menu/(longer names above are greedily matched first to prevent partial mismatches)#animationredirects toguide/animation/.#about,#install,#bundling,#token-systemand#themesare still valid for the original landing page.#page-gridstill redirects as one would expect to its corresponding component page).For components, it redirects safely by ensuring that it matches longer component names first and it automatically matches based on actual URLs mentioned in the page navigation (to prevent blindly redirecting to arbitrary URLs).
Operates on the following conventions:
#pagination-overflow-horizontal-24-controlor#toggle-button-group-x1)tab-defaultandtab-faketo be consistentlytabs-prefixedTesting locally
git clone https://github.com/patricknelson/skin.git cd skin git checkout fix-legacy-links npm i npm run startLinks from above (for validation):
Checklist
This is an ac hoc cowboy PR (no issue was created for this) 🤠