Create componentWithErrorBoundary HOC for more graceful failure

[faridsalau]

Description

Added a new Higher Order Component (HOC) componentWithErrorBoundary that wraps React components with error boundary functionality. This HOC:

• Catches JavaScript errors during rendering, in lifecycle methods, and in constructors
• Prevents the entire app from breaking when individual components fail
• Provides a clean way to render fallback UI when errors occur
• Reports errors to sentry for tracking

Why

Currently, unhandled errors in any component can cause the entire app to break.

By implementing error boundaries, we can:

1. Improve app stability and user experience
2. Isolate failures to specific components
3. Better track and monitor component-level errors
4. Maintain core functionality even when enhancement features fail

When to Use

Apply this HOC to components that:

• Can fail independently without breaking core functionality
• Have clear fallback states
• Depend on external data or API calls
• Enhance but aren't critical to the user experience

Examples:

// Good: Enhancement feature that can fail safely
const ArtistRecommendationsWithErrorBoundary = componentWithErrorBoundary(ArtistRecommendations)

// Good: Individual list item that should fail independently
const TrackTileWithErrorBoundary = componentWithErrorBoundary(TrackTile)

Do NOT use for:

• Main layout components (i.e. the entire left nav)
• Authentication components
• Essential playback controls

Implementation Note

For this initial PR, all error boundary instances will render null as their fallback UI.

How Has This Been Tested?

The ProfileTopTags component is currently causing a full screen error. Added HOC and checked if it stopped showing the fullscreen error and that it logged the error to console

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9514043

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[dylanjeffers]

Do we need to wrap all these components with error boundary? imo maybe it makes sense to target "Page" and "Modal", and then maybe areas that we think are prone to errors?

[faridsalau]

Do we need to wrap all these components with error boundary? imo maybe it makes sense to target "Page" and "Modal", and then maybe areas that we think are prone to errors?

My take here is that we should be as detailed & low level with these error boundaries as possible. And leave AppErrorBoundary to catch Page level errors that aren't handled by more localized error boundaries.

If, for example, a like button is erroring...who cares, we should take it out of the DOM and let the rest of the app be as is. as long as the listening experience isn't affected and the removal of an item doesn't break the whole flow, things should either render as null or show their own individual error state and the rest of the app should be left alone. a small thing breaking in a modal, such as a like button, shouldn't bork the whole modal, so we shouldn't only leave the error boundaries so high up.

maybe areas that we think are prone to errors

I think yes, that was the methodology I attempted to go with here, but lmk if you think any of these files don't follow that. the general thinking here is that these follow one of:

• Can fail independently without breaking core functionality
• Have clear fallback states
• Depend on external data or API calls
• Enhance but aren't critical to the user experience

We should also discuss error states with design. Perhaps some of these should have their own error UI instead of just returning null. But for now, I think null is ok