What is @sentry/react?
The @sentry/react package is designed for error monitoring and performance tracking in React applications. It provides a comprehensive set of tools to capture exceptions, track performance issues, and improve the overall reliability of React applications. By integrating Sentry into a React project, developers can gain insights into errors and performance bottlenecks, allowing for quicker debugging and optimization.
What are @sentry/react's main functionalities?
Error Boundary
This feature automatically catches JavaScript errors anywhere in the child component tree of the Error Boundary and logs them to Sentry. It also displays a fallback UI instead of the component tree that crashed.
import React from 'react';
import * as Sentry from '@sentry/react';
const MyApp = () => (
<Sentry.ErrorBoundary fallback={'An error has occurred'}>
<YourApp />
</Sentry.ErrorBoundary>
);
Performance Monitoring
Enables performance monitoring in your React application. By setting the `tracesSampleRate` to a value between 0 and 1, you can control the percentage of transactions sent to Sentry for performance analysis.
import * as Sentry from '@sentry/react';
Sentry.init({
dsn: 'YOUR_DSN',
tracesSampleRate: 1.0,
});
Custom Error Tracking
Allows for manual reporting of errors or exceptions to Sentry, giving developers the flexibility to capture specific issues that may not be automatically detected.
import * as Sentry from '@sentry/react';
Sentry.captureException(new Error('This is my custom error.'));
Other packages similar to @sentry/react
logrocket
LogRocket is a frontend application monitoring solution that provides session replay, performance monitoring, and error tracking. While it offers similar error tracking capabilities to @sentry/react, LogRocket distinguishes itself with its session replay feature, allowing developers to see exactly what users saw when an error occurred.
bugsnag
Bugsnag offers error monitoring and application stability management for various programming languages and frameworks, including React. Compared to @sentry/react, Bugsnag emphasizes application stability metrics and provides detailed error grouping and analysis, making it easier to prioritize and fix critical errors.
Official Sentry SDK for ReactJS
Links
General
This package is a wrapper around @sentry/browser
, with added functionality related to React. All methods available in
@sentry/browser
can be imported from @sentry/react
.
To use this SDK, call Sentry.init(options)
before you mount your React component.
import React from 'react';
import { createRoot } from 'react-dom/client';
import * as Sentry from '@sentry/react';
Sentry.init({
dsn: '__DSN__',
});
const container = document.getElementById(“app”);
const root = createRoot(container);
root.render(<App />);
React 19
Starting with React 19, the createRoot
and hydrateRoot
methods expose error hooks that can be used to capture errors
automatically. Use the Sentry.reactErrorHandler
function to capture errors in the error hooks you are interested in.
const container = document.getElementById(“app”);
const root = createRoot(container, {
onUncaughtError: Sentry.reactErrorHandler((error, errorInfo) => {
console.warn('Uncaught error', error, errorInfo.componentStack);
}),
onCaughtError: Sentry.reactErrorHandler(),
onRecoverableError: Sentry.reactErrorHandler(),
});
root.render(<App />);
If you want more finely grained control over error handling, we recommend only adding the onUncaughtError
and
onRecoverableError
hooks and using an ErrorBoundary
component instead of the onCaughtError
hook.
ErrorBoundary
@sentry/react
exports an ErrorBoundary component that will automatically send Javascript errors from inside a
component tree to Sentry, and set a fallback UI.
app.js
import React from 'react';
import * as Sentry from '@sentry/react';
function FallbackComponent() {
return <div>An error has occurred</div>;
}
class App extends React.Component {
render() {
return (
<Sentry.ErrorBoundary fallback={FallbackComponent} showDialog>
<OtherComponents />
</Sentry.ErrorBoundary>
);
}
}
export default App;
Profiler
@sentry/react
exports a Profiler component that leverages the tracing features to add React-related spans to
transactions. If tracing is not enabled, the Profiler component will not work. The Profiler tracks component mount,
render duration and updates.
app.js
import React from 'react';
import * as Sentry from '@sentry/react';
class App extends React.Component {
render() {
return (
<FancyComponent>
<InsideComponent someProp={2} />
<AnotherComponent />
</FancyComponent>
);
}
}
export default Sentry.withProfiler(App);
8.41.0
Important Changes
-
meta(nuxt): Require minimum Nuxt v3.7.0 (#14473)
We formalized that the Nuxt SDK is at minimum compatible with Nuxt version 3.7.0 and above.
Additionally, the SDK requires the implicit nitropack
dependency to satisfy version ^2.6.1
and ofetch
to satisfy ^1.3.3
.
It is recommended to check your lock-files and manually upgrade these dependencies if they don't match the version ranges.
Deprecations
We are deprecating a few APIs which will be removed in the next major.
The following deprecations will potentially affect you:
-
feat(core): Update & deprecate undefined
option handling (#14450)
In the next major version we will change how passing undefined
to tracesSampleRate
/ tracesSampler
/ enableTracing
will behave.
Currently, doing the following:
Sentry.init({
tracesSampleRate: undefined,
});
Will result in tracing being enabled (although no spans will be generated) because the tracesSampleRate
key is present in the options object.
In the next major version, this behavior will be changed so that passing undefined
(or rather having a tracesSampleRate
key) will result in tracing being disabled, the same as not passing the option at all.
If you are currently relying on undefined
being passed, and and thus have tracing enabled, it is recommended to update your config to set e.g. tracesSampleRate: 0
instead, which will also enable tracing in v9.
The same applies to tracesSampler
and enableTracing
.
-
feat(core): Log warnings when returning null
in beforeSendSpan
(#14433)
Currently, the beforeSendSpan
option in Sentry.init()
allows you to drop individual spans from a trace by returning null
from the hook.
Since this API lends itself to creating "gaps" inside traces, we decided to change how this API will work in the next major version.
With the next major version the beforeSendSpan
API can only be used to mutate spans, but no longer to drop them.
With this release the SDK will warn you if you are using this API to drop spans.
Instead, it is recommended to configure instrumentation (i.e. integrations) directly to control what spans are created.
Additionally, with the next major version, root spans will also be passed to beforeSendSpan
.
-
feat(utils): Deprecate @sentry/utils
(#14431)
With the next major version the @sentry/utils
package will be merged into the @sentry/core
package.
It is therefore no longer recommended to use the @sentry/utils
package.
-
feat(vue): Deprecate configuring Vue tracing options anywhere else other than through the vueIntegration
's tracingOptions
option (#14385)
Currently it is possible to configure tracing options in various places in the Sentry Vue SDK:
- In
Sentry.init()
- Inside
tracingOptions
in Sentry.init()
- In the
vueIntegration()
options - Inside
tracingOptions
in the vueIntegration()
options
Because this is a bit messy and confusing to document, the only recommended way to configure tracing options going forward is through the tracingOptions
in the vueIntegration()
.
The other means of configuration will be removed in the next major version of the SDK.
-
feat: Deprecate registerEsmLoaderHooks.include
and registerEsmLoaderHooks.exclude
(#14486)
Currently it is possible to define registerEsmLoaderHooks.include
and registerEsmLoaderHooks.exclude
options in Sentry.init()
to only apply ESM loader hooks to a subset of modules.
This API served as an escape hatch in case certain modules are incompatible with ESM loader hooks.
Since this API was introduced, a way was found to only wrap modules that there exists instrumentation for (meaning a vetted list).
To only wrap modules that have instrumentation, it is recommended to instead set registerEsmLoaderHooks.onlyIncludeInstrumentedModules
to true
.
Note that onlyIncludeInstrumentedModules: true
will become the default behavior in the next major version and the registerEsmLoaderHooks
will no longer accept fine-grained options.
The following deprecations will most likely not affect you unless you are building an SDK yourself:
- feat(core): Deprecate
arrayify
(#14405) - feat(core): Deprecate
flatten
(#14454) - feat(core): Deprecate
urlEncode
(#14406) - feat(core): Deprecate
validSeverityLevels
(#14407) - feat(core/utils): Deprecate
getNumberOfUrlSegments
(#14458) - feat(utils): Deprecate
memoBuilder
, BAGGAGE_HEADER_NAME
, and makeFifoCache
(#14434) - feat(utils/core): Deprecate
addRequestDataToEvent
and extractRequestData
(#14430)
Other Changes
- feat: Streamline
sentry-trace
, baggage
and DSC handling (#14364) - feat(core): Further optimize debug ID parsing (#14365)
- feat(node): Add
openTelemetryInstrumentations
option (#14484) - feat(nuxt): Add filter for not found source maps (devtools) (#14437)
- feat(nuxt): Only delete public source maps (#14438)
- fix(nextjs): Don't report
NEXT_REDIRECT
from browser (#14440) - perf(opentelemetry): Bucket spans for cleanup (#14154)
Work in this release was contributed by @NEKOYASAN and @fmorett. Thank you for your contributions!