At the company I work at, we’re building with Elm and Elm-land. The toolkit that we use for building the UI consists mainly of pre-built and custom web-components.
With Elm-land, we’re running into a problem where <a> elements within these web-components are not triggering the SPA routing and are instead causing a full reload. This is obviously less-than-optimal for the user experience. We expect this issue to occur since Elm probably cannot attach event-handlers to these anchor elements, since they exist in a Shadow DOM, meaning JavaScript at root level is isolated from the inner workings of the web-component, by design. As far as I know, Elm-land uses the Elm routing utilities.
Has this problem ever been solved before? Or is anyone able to give some pointers here? Would like to know what the community thinks.
You are right that a (closed) shadow root isn’t accessible from the outside (unless using nasty hacks), but that’s not what is happening in your case – Shadow DOM is not related.
Every <a> created by a certain Browser.application instance get a click listener attached that does the SPA stuff. In your case, it sounds like you have <a> elements that Elm didn’t create, but you still want to Elm SPA routing for them.
I think you should be able to add a delegated event listener in your web component root that listens for clicks anywhere within the component. The listener would check if the click was on a link, and then do the same checks as Elm does in its link click listeners, except you’d be calling a port in the end. In update when getting stuff on the port, you could call the same logic as for your onUrlRequest and onUrlChange. Or whatever the equivalent is in Elm Land. (I have never written an Elm Land app myself so I unfortunately don’t know if there’s any tricky things you could encounter there.)