Track React Components
Sentry helps you track your React components and unlock additional insights in your application. You can set it up to track React component names as well as monitor the performance of your React components with component tracking.
So instead of looking at selectors like this:
button.en302zp1.app-191aavw.e16hd6vm2[role="button"][data-test-id="common-options"]
You can also see exactly which React component was used, like:
CommonOptions
You can track the names of React components in your application via a Babel plugin, which can unlock powerful workflows and decrease ambiguity. For example, you can search for replays where a specific React component was clicked on. You can also see the name of the component that was clicked on in breadcrumbs and spans on Sentry's Performance page. This significantly decreases the amount of ambiguity involved in figuring out which element was interacted with as compared to trying to figure it out by looking at the element's CSS selector alone (which becomes even more ambiguous after the minification process).
We're working to release more features that will leverage component name tracking in the future and highly recommended that you configure your project to use it.
Please note that your Sentry browser SDK must be at version 7.91.0
or higher before you can use these features. Only React components in .jsx
or .tsx
files can be tracked.
There are two different ways you can set up React component name tracking in your application:
- By installing Sentry's bundler plugins
- By directly installing @sentry/babel-plugin-component-annotate
We recommend that you use the first option because the Sentry bundler plugins come packed with additional useful features to enrich your Sentry workflows, including: automatic sourcemap upload, release creation, automatic release name discovery, and release injection.
Set up using bundler plugins:
Follow the instructions in the npm page for the bundler that your project uses:
Please note that although there is a Sentry bundler plugin for esbuild, React component name tracking is currently not supported.
Once you've followed the instructions to install the bundler plugin and added it to your bundler's config, enable component name tracking by setting the flag for it to true
:
// Example specific to Vite, see documentation for other bundlers
sentryVitePlugin({
// ... other options above
reactComponentAnnotation: { enabled: true }
}),
If you're using Rollup as your bundler, ensure that you place sentryRollupPlugin
before any other plugins that transform your JSX.
Now, you will be able to see your component names in breadcrumbs, spans, and search for replays by component names. See this page for more information on searching for Replays by component name.
The Babel plugin parses your application's JSX source code at build time, and applies additional data
attributes onto it. These attributes then appear on the DOM nodes of your application's built HTML, indicating the React component and file that each node is sourced from.
For example, if you had a component named MyAwesomeComponent
in the file myAwesomeComponent.jsx
:
function MyAwesomeComponent() {
return <div>This is a really cool and awesome component!</div>
}
After your bundler applied the plugin and built your project, the resulting DOM node would look like this:
<div data-sentry-component="MyAwesomeComponent" data-sentry-source-file="myAwesomeComponent.jsx">This is a really cool and awesome component!</div>
The Sentry browser SDK will pick off the value from these data
attributes and collect them when your components are interacted with.
Sentry's React SDK offers a feature to monitor the performance of your React components: component tracking. The SDK exports a withProfiler
higher-order component that attaches React related spans to the current active transaction on the scope. This allows you to get a drilled-down view into how your components are behaving so you can do things like identify slow mounts or frequent updates, which might have an impact on your app's performance.
To set up component tracking, you need to configure performance monitoring. For details on how to do this, check out our Performance documentation.
In the example below, the withProfiler
higher-order component is used to instrument an app component.
import React from "react";
import * as Sentry from "@sentry/react";
class App extends React.Component {
render() {
return (
<FancyComponent>
<NestedComponent someProp={2} />
<AnotherComponent />
</FancyComponent>
);
}
}
export default Sentry.withProfiler(App);
The React Profiler currently generates spans with three different kinds of op-codes: ui.react.mount
, ui.react.render
, and ui.react.update
.
ui.react.mount
The span that represents how long it took for the profiled component to mount.
ui.react.render
The span that represents how long the profiled component was on a page. This span is only generated if the profiled component mounts and unmounts while a transaction is occurring.
ui.react.update
The span that represents when the profiled component updated. This span is only generated if the profiled component has mounted.
In React Strict Mode, certain component methods will be invoked twice. This may lead to duplicate ui.react.mount
spans appearing in a transaction. React Strict Mode only runs in development mode, so this will have no impact on your production traces.
The withProfiler
higher-order component has a variety of options for further customization. They can be passed in as the second argument to the withProfiler
function.
export default Sentry.withProfiler(App, { name: "CustomAppName" });
name
(string)
The name of the component being profiled. By default, the name is taken from the component displayName
property or the component name
property.
includeRender
(boolean)
If a ui.react.render
span should be created by the Profiler. Set as true by default.
includeUpdates
(boolean)
If react.update
spans should be created by the Profiler. Set as true by default. We recommend setting this prop as false for components that will experience many rerenders, such as text input components, as the resulting spans can be very noisy.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").