getsentry / getsentry/sentry-javascript

Investigate NextResponse.rewrite for route parameterization

Aberta
#17,843 9 comentários 4 reações 0 responsáveis Ver no GitHub
Next.js
Linguagem predominante
TypeScript
Estrelas
8.7k
Forks
1.8k
Merge médio
1d 18h
PRs com merge (30d)
541

Descrição

### Problem Statement

Oftentimes I want to differentiate `navigation` spans of different pages that have the same path shape:
* `/:locale` -> index page
* `/palm-tree` -> product details page
* `/sansevieria` -> product details page
* `/accessories` -> static page

I need this when I'm building pageload dashboard widgets, and currently I can't easily filter spans based on the page (ex. index, product details, accessories, etc.).

Neither `navigation` or `pageload` spans contain anything that describes which page in my project rendered them. Examples from my project:
* [`/pothos`](https://nikolovlazar.sentry.io/explore/traces/trace/f12ae266062946318681fdea7cc5fee3/?node=span-b79895f852994a30&project=4510082016935936&query=span.op%3Anavigation&source=traces&statsPeriod=7d&targetId=b79895f852994a30×tamp=1759330221) -> Product Details (dynamic) `navigation` span
* [`/sansevieria`](https://nikolovlazar.sentry.io/explore/traces/trace/2adfa3610dc04e0dbd03935a1c93d65a/?node=span-812cf568fd84bda0&project=4510082016935936&query=span.op%3Anavigation&source=traces&statsPeriod=7d&targetId=812cf568fd84bda0×tamp=1759330152) -> Product Details (dynamic) `navigation` span
* [`/:locale`](https://nikolovlazar.sentry.io/explore/traces/trace/31b69e59eef20fd7941c6aa63ab47e80/?node=span-a12ed5108b9747a1&project=4510082016935936&query=span.op%3Apageload&source=traces&statsPeriod=7d&targetId=a12ed5108b9747a1×tamp=1759174962) -> Index (static) `pageload` span
* [`/accessories`](https://nikolovlazar.sentry.io/explore/traces/trace/ef7245c13d97436ba3eb3a9756731482/?node=span-bdee8b0d39b4f8fe&project=4510082016935936&query=span.op%3Anavigation&source=traces&statsPeriod=7d&targetId=bdee8b0d39b4f8fe×tamp=1759161211) -> Accessories (static) `navigation` span

The closest I can get to building a widget that targets specific pages is to use a lot of `span.description is not '***'` filters, but no one wants to do that.

### Solution Brainstorm

One approach that comes to mind is to modify the root span in each page and add custom attributes to it:
```javascript
const activeSpan = Sentry.getActiveSpan();
const rootSpan = activeSpan && Sentry.getRootSpan(activeSpan);

if (rootSpan) {
rootSpan.setAttribute('page', 'product-details');
}
```

The safest way would be to put this in a `useEffect` inside of my Next.js page component so it doesn't run on every render. But there's a catch - since Next.js renders the pages on the server by default, to achieve this I'm going to have to create a client component, mark it with `'use client'` so it can run the effect, and then use it in the page. A whole separate client component just to add a single attribute to the root span. We should come up with an easier way to do this.

### Additional Context

Technically there are two issues described in this GitHub issue:
* Root spans of Next.js pages do not contain info on which page component rendered them
* Modifying / adding attributes to the root span in a server-rendered Next.js page is cumbersome and involves creating an empty client component

I understand this has a lot to do with how Next.js works, how it renders pages, how it executes code on the server vs the client, but we should look into improving the two things mentioned above.

Here's the repo I'm working in: https://github.com/nikolovlazar/catalyst-sentry

Tip: React with 👍 to help prioritize this improvement. Please use comments to provide useful context, avoiding `+1` or `me too`, to help us triage it.

Guia de contribuição

Abrir o guia de contribuição

Direção de pesquisa

Comece reproduzindo os exemplos vinculados de catalyst-sentry para páginas dinâmicas e estáticas do Next.js e, em seguida, investigue como NextResponse.rewrite e a execução de páginas renderizadas no servidor afetam os spans raiz e de navegação do Sentry. A implementação concluída deve fornecer uma identidade de página confiável nos spans relevantes e uma maneira menos trabalhosa de adicionar atributos sem um componente cliente que, de outra forma, ficaria vazio.

Escrita pelo modelo de indexação a partir do texto da issue.

Avaliação

Stack de tecnologia
nextjs, react, typescript
Domínio
frontend, observability
Tipo de issue
Funcionalidade
Dificuldade
5/5
Tempo estimado
Mais de uma semana
Status de atividade
Estagnada
Clareza
Precisa de esclarecimento
Facilidade para iniciantes
32/100

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.