I'll come back on the gaps or feature requests in specific

Looking at the other sentry libs for JS frontend frameworks it looks like they are all hooking into their frameworks respective routers. The "react" lib is in fact the "react router" library, if I'm. reading the docs correctly. Conversely lit doesn't have a de facto router, there's one under the "lit-labs" scope but that means that it's not ready for production yet.

They currently have browserTracingIntegration set in the Sentry initialisation. That's been working great but they aren't sending any SPA navigations from the app. Since they are using Lit and their own custom router (lit doesn't have a production ready canonical router) they tried previously setting up custom routing via: https://docs.sentry.io/platforms/javascript/performance/instrumentation/automatic-instrumentation/#custom-routing. This ended up dropping all the performance instrumentation, possibly because we couldn't get the startBrowserTracingPageLoadSpan function called early enough in the apps lifecycle.

So might be worth looking into to see what we can already do

Is there any example code available of how other routers are integrated with sentry?

Here's react router!

Here is vue:

To add onto this discussion a little bit: creating the spans isn't necessarily a problem, since we can manually create inactiveSpans and start/close them in different Lit callbacks. The problem is the async loading of (sub-)components and actually knowing when all sub-components of one parent are fully loaded. We have tried looking into waiting for all child components' updateComplete callback as follows:

async getUpdateComplete() {
 // Wait for updateComplete from this component first
 await super.getUpdateComplete();
 // Find all Lit children in the shadow DOM
 const childComponents = Array.from(this.shadowRoot.querySelectorAll('*'))
 .filter(el => el instanceof LitElement); // Alleen LitElement instances
 // Wait for updateComplete from all children
 await Promise.all(childComponents.map(child => child.updateComplete));
 // Return true to indicate updateComplete
 return true;
}

Unfortunately this didn't work since in our specific case the sub-components are rendered conditionally, they do not exist in the shadow DOM for a while when loading the component / when checking in the parent's lifecycle callbacks. This again leads us to unusable Sentry spans (i.e. the manually created span is already closed before the Long UI Task in the trace). The only way I found to (semi-)reliably check if all sub-components are loaded is with a MutationObserver:

// Set up the MutationObserver
this.observer = new MutationObserver((mutations) => {
 mutations.forEach(() => {
 this._lastObservation = performance.now();
 this._observerIdle = false;
 });
});
// Start observing the component's shadow DOM
this.observer.observe(this.shadowRoot, { childList: true, subtree: true });
this.checkObserverIdle = setInterval(() => {
 if (this._observerIdle) {
 clearInterval(this.checkObserverIdle);
 } else {
 this._observerIdle = true;
 }
}, this._idleInterval);

However, I can imagine this is not the most appropriate approach when you have tons of separate components on a Single Page App.

I wonder if https://developer.mozilla.org/en-US/docs/Web/API/Element/elementTiming can be leveraged here. It does have a restriction in the kind of elements it supports though unfortunately.

Hey @AbhiPrasad -> I managed to setup a test app https://github.com/Angelodaniel/lit-components-custom-instrumentation
"The InstrumentedLitElement uses both a MutationObserver and recursive updateComplete checks to ensure spans only end when the entire subtree is rendered." is this something that we can review? I didn't see any other options for now.
Seems this is what we need: lit/lit#3538