As the solution is meant for single Hype widgets (meaning only works if there is not more than one Hype document on a webpage), to get a hypeDocument solution for a multi Hype widget setup, here is a quick insight in what is going on behind the scenes. Hype actually has a global lookup of all the Hype widgets on a page, and it can be found under HYPE.documents (← check it out in your browser console). Under that JavaScript object, every hypeDocument is listed by its document ID, and that is in turn based on its document name. There in lies the challenge of hard-coding as it introduces the dependent on your Hype document name. Hence, renaming your document would lead to refactoring your hard-coded links and another quirk with this lookup is that when you only preview in Hype, the preview mode doesn't use the document name (hence ID) you assigned it, but calls it index.
Hence, the above workaround of capturing the local hypeDocument on the event Hype Document Load and assigning it to a global variable called hypeDocument. As this event fires for every Hype widget on a page, you can see how this could fail in such a scenario. The moment you have more than one Hype widget on a page, the last one initialized will populate the global hypeDocument produced by this method and might lead to some unintended behavior. This solution is viable and shouldn't be a problem as long as one can be sure that there is only one Hype widget on a page or all are running from within iFrames.
Don't get me wrong the lookup is still a valuable thing, although using it directly, through hard-coding can be challenging. One initial workaround was to auto-detect the hypeDocument from withing a rectangle:
If you are a Hype Actions Event user, you can also simply use action events to capture change using data-change-action and map it to a function or direct JavaScript as seen here: