Supportability of the Lit framework

[Angelodaniel]

Problem Statement

Some customers have been using the https://lit.dev/ framework and are forced to use the Javascript SDK as we don't have a SDK for this.

This can also create some gaps as there is no Automatic instrumentation for Performance for Lit in specific.

Solution Brainstorm

https://lit.dev/

┆Issue is synchronized with this Jira Improvement by Unito

[Lms24]

Hey @Angelodaniel I'm gonna convert this to a discussion for the moment because that's how we track currently unsupported frameworks.

That being said, it'd be great to find out more where our @sentry/browser SDK currently has shortcomings for Lit. For instance: Do we need a custom routing instrumentation for a client-side router? Are errors not getting caught correctly?
Appreciate feedback from anyone following this issue/discussion.

[Angelodaniel]

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

[koddsson]

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.

[Angelodaniel]

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

[michellangeveld]

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

[AbhiPrasad]

Here's react router!

sentry-javascript/packages/react/src/reactrouterv3.ts

Line 44 in a0415aa

export function reactRouterV3BrowserTracingIntegration(

Here is vue:

sentry-javascript/packages/vue/src/browserTracingIntegration.ts

Lines 49 to 74 in a0415aa

	export function browserTracingIntegration(options: VueBrowserTracingIntegrationOptions = {}): Integration {
	// If router is not passed, we just use the normal implementation
	if (!options.router) {
	return originalBrowserTracingIntegration(options);
	}
	const integration = originalBrowserTracingIntegration({
	...options,
	instrumentNavigation: false,
	});
	const { router, instrumentNavigation = true, instrumentPageLoad = true, routeLabel = 'name' } = options;
	return {
	...integration,
	afterAllSetup(client) {
	integration.afterAllSetup(client);
	const startNavigationSpan = (options: StartSpanOptions): void => {
	startBrowserTracingNavigationSpan(client, options);
	};
	instrumentVueRouter(router, { routeLabel, instrumentNavigation, instrumentPageLoad }, startNavigationSpan);
	},
	};
	}

[Angelodaniel]

Hey Team, I'm working on a Single page app where there are multiple Lit framework components which show up "nameless". We have some long ui tasks that we want to try and correlate to these components so it's more obvious that Component A is responsible for the Long UI task.
What would be the best way to instrument those?
See Notion case for Customer specific context - Here

@timfish mentioned: I was going to suggest how to instrument the callbacks but it sounds like you're already doing that!
It does sound like the issues they’re having are due to the lack of async context in the browser. We can’t link up spans across async await

[Koen-Reefman]

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.