[EuiErrorBoundary] Use lighter components for EuiErrorBoundary

[cleydyr]

Problem Statement

I'm digging a bit on optimizing our bundles for an app that uses EUI. I noticed that we're loading EuiCodeBlock in EuiErrorBoundary only to wrap the error message and its title.  But EuiCodeBlock is very powerful and often results in code that is rarely used (mainly for syntax highlighting).

Proposed Solution

Use a lighter component to help render the error message and title.

Value / Impact

• Reduce the app bundle size for consumers
• Reduce the amount of unused Javascript

Urgency

Not urgent.

Do alternatives or workarounds exist?

Lazily-loading EuiCodeBlock and EuiErrorBoundary to render them only when an actual error happens.

[JasonStoltz]

@cleydyr Thanks for the issue. I'm moving this one to the backlog, but I don't know when or if we'll prioritize it.

It's quite valid, but I don't think this ranks high as a problem to solve for us right now.

We can definitely reconsider if it's causing major issues for any of our core apps. And if ya have a proposal in mind, feel free to post it here or put up a draft PR for us to consider.

[JasonStoltz]

Capturing some discussion from a Triage discussion with the team and Clint:

The underlying concern may bigger than the choice of inner component.

The core question is whether EuiErrorBoundary is loaded asynchronously. As a last-resort boundary that only renders when an unexpected error occurs, its weight (including EuiCodeBlock) shouldn't matter if it's lazy-loaded. If it's being statically bundled regardless of whether an error ever fires, that's the real problem to fix — and would make the inner-component swap largely moot. The workaround (lazily loading both EuiCodeBlock and EuiErrorBoundary, rendering only on actual error) points in this direction. Worth confirming whether EuiErrorBoundary is async by default today; it doesn't appear to be.

There's also an API/role question to settle before any change:

Is EuiErrorBoundary intended strictly as the last boundary a user hits (developer-facing, shows the error stack, no customization) — which is roughly how it's implemented now?
Or should it expose an API so consumers can render their own, more user-friendly error UI? (Shared UX has built a friendlier error boundary; note EuiProvider also wraps an EuiErrorBoundary.)
A related, optional consideration: whether rendering full (minified, hard-to-read) JS stack traces in production deployments is desirable from a UX standpoint at all — separate from this bundling issue, but adjacent.

Recommendation for if/when picked up: Frame the work as "should EuiErrorBoundary be async by default?" rather than "replace EuiCodeBlock." Decide the component's intended role (last-resort vs. customizable) first, since it determines the right fix. Currently low priority — not a new or critical bug — but there may be a small, high-value task here (making the boundary async) once we have the appetite.

[DevLikhith5]

I'd like to work on this.

The plan:

• Replace EuiCodeBlock in EuiErrorMessage with a plain <pre> element styled via the existing euiErrorBoundaryStyles
• Keep EuiTitle and EuiI18n since they're lightweight and appropriate for the heading
• Update the styles file to add basic code/pre styling so the error message still renders with proper monospace formatting

EuiCodeBlock pulls in syntax highlighting infrastructure that's never used here (the error output is plain text). Dropping it reduces bundle size without any functional change since the error boundary only renders during crashes anyway.

Does that approach sound right?