# Source context

> How Snags finds the component behind an element, reads the site's release and links to the file in your repository.

When you comment on an element, Snags tries to tell whoever fixes it where that element lives in the code: the component that rendered it, the file and line, and the release of the site you were looking at. It shows on the audit page and in what your [coding agent](/docs/mcp) reads.

Nothing here needs setting up to comment. It fills in when the site gives Snags something to read.

## The component behind an element

Frameworks keep track of which component rendered each element, and development builds keep more of it. Snags reads:

- **React** development builds, including the file and line of the JSX
- **Vue** 2 and 3
- **Svelte** and **Angular** development builds
- the `data-*` attributes that build plugins add to elements, such as Sentry's component annotation, LocatorJS and react-dev-inspector

File paths are trimmed to your project, from `src/`, `app/`, `pages/`, `components/` or `lib/` onwards.

Production builds usually strip component names. On a live site you'll often get a selector and the element's text rather than a component, unless the site uses an annotation plugin. Audit a staging or preview build when you want the fullest context.

## The site's release

Snags reads the site's release and environment from the page itself:

- meta tags such as `version`, `release`, `build` and `commit`
- common globals, such as Sentry's release, Next.js's build id and app-defined version variables
- the hostname, to tell production from staging, preview and local

A comment that knows the release turns "when did this break?" into a comparison between two versions.

## Links to your repository

When you publish, you can give the site's repository on GitHub, GitLab or Bitbucket. Snags remembers it for that site.

Each comment's component then links to its file in the repository. When the page announced its commit, the link opens the file at that commit, so it shows the code you were actually looking at rather than whatever is on the main branch now.

## Treat it as a starting point

A component and a file are a lead, not proof of what caused the problem. Shared components, framework code and minified bundles can point at the wrong place, or nowhere at all.