The key is remembering Basecamp’s philosophy. The JS is merely decorating the HTML they already have. As @chrisgrande said; the crux of it is that humble line of HTML, hidden in the
<a class="undecorated push_half--right" data-turbo-frame="my_stuff" data-popup-menu-target="link" href="/me" hidden="">My stuff</a>
Remember this: it’s a plain old link. Or at least, it looks like one, and if JS was disabled, it should work like one and simply navigate to
That’s not what actually happens, of course. But the awesome thing about what happens next is how much is leveraging standard browser behaviour and just decorating it to enhance it.
The element pulling the extra strings is the popup menu controller. This listens for the same toggle event that the
<summary> sends to open the
<details> dropdown, and on hearing that, it simply clicks the link.
Again, if there was a problem with turbo frames, this would simply navigate you to
However, the turbo-frame element has other ideas. It has previously registered an interest in all turbo:click events, and intercepts this one. The link is the target of the event, and it sees the link’s
data-turbo-frame matches its own
id, and that is the hook by which is decides it must be on lazy-loading duty, appropriates the click event, and pulls the
href of the link to use as its own
src going forward, i.e. it fetches
In the meantime the animation of the
<details open> is running and if you are very lucky it completes at the exact moment the frame’s XHR round-trip completes.
That’s how it works. The popup menu controller is just a Stimulus controller, and the
<turbo-frame> element is a custom element from the Web Components API, and they’re just riffing off a plain old
<a href> in an otherwise fairly standard
<details>/<summary> construction. Ultimately, the whole mechanism is delegating a ton of work back to standard browser behaviours, and can therefore gracefully degrade when JS is disabled or glitching.