State Management and Error Handling Strategy

• Local component state — a property that only that one component cares about.
• Parent-child shared state — passed down via @api properties, communicated back up via CustomEvent (Module 5).
• Unrelated-component shared state — Lightning Message Service (Module 5), for components with no direct parent-child relationship.

Unlike some single-page-app frameworks, LWC has no built-in global state store by default — state is deliberately kept close to where it's needed, using the mechanisms above rather than one giant shared object. This makes deliberately choosing where a given piece of state belongs more important, not less.

// errorUtils.js — one shared pattern used everywhere
import { ShowToastEvent } from 'lightning/platformShowToastEvent';

export function reduceErrorMessage(error) {
    return error?.body?.message ?? 'An unexpected error occurred.';
}

export function showErrorToast(component, error, title = 'Error') {
    component.dispatchEvent(new ShowToastEvent({
        title,
        message: reduceErrorMessage(error),
        variant: 'error',
    }));
}

Rather than each component inventing its own ad hoc error-handling approach, a small, shared, importable module (Module 4's export/import) standardizes it — every component calls showErrorToast(this, error) and gets the same consistent behavior, rather than one showing a toast, another a console log, and a third silently swallowing the error entirely.

Inconsistent error handling across dozens of components in a real org becomes a genuine maintenance and user-experience problem — users see different, unpredictable feedback for the same class of failure depending on which component happened to hit it, and developers waste time re-inventing the same handling logic differently each time.