Summary
Currently, all error handling across the codebase uses bare console.error() calls with no mechanism for host applications to detect or respond to failures. When asset data fails to load, the modal shows an infinite loading shimmer with no error feedback, and embedding websites have no way to implement fallback UI, retry logic, or error monitoring.
Problem
- Silent failures:
fetchAsset() in src/asset/asset-service.ts returns undefined on network errors or non-OK responses (lines 15-19, 67-69). The modal continues showing shimmer placeholders indefinitely.
- No host integration: Embedding websites cannot detect when Capture Eye fails — there are no events, callbacks, or observable states exposed.
- Unobservable tracking errors:
InteractionTracker.createEvent() in src/modal/interaction-tracker.ts (lines 86-88) logs errors to console but provides no external signal of failure.
- No retry capability: Once a fetch fails, there is no way for the host application to trigger a retry without removing and re-adding the component.
Proposed Approach
1. Dispatch capture-eye-error CustomEvent from the <capture-eye> component
// In capture-eye.ts or modal-manager.ts, after a fetch failure:
this.dispatchEvent(new CustomEvent('capture-eye-error', {
bubbles: true,
composed: true, // Cross shadow DOM boundary
detail: {
type: 'fetch-asset' | 'fetch-metadata' | 'event-tracking',
nid: this.nid,
message: error.message,
timestamp: new Date().toISOString(),
},
}));
2. Dispatch capture-eye-loaded success event
this.dispatchEvent(new CustomEvent('capture-eye-loaded', {
bubbles: true,
composed: true,
detail: { nid: this.nid },
}));
3. Add an error state to the modal
Instead of infinite shimmer on fetch failure, show a minimal error state (e.g., "Unable to load asset data") with an optional retry action.
Affected Files
src/asset/asset-service.ts — Error handlers at lines 15-19, 67-69, 85-88, 113-116
src/modal/modal-manager.ts — Where fetchAsset results are consumed
src/modal/modal.ts — Add error state rendering alongside shimmer/loaded states
src/capture-eye.ts — Expose events to host applications
Expected Impact
- Host applications can implement error boundaries and fallback UI
- Production monitoring tools can track Capture Eye reliability
- Users see clear error feedback instead of infinite loading states
- Improved developer experience for integrators
Summary
Currently, all error handling across the codebase uses bare
console.error()calls with no mechanism for host applications to detect or respond to failures. When asset data fails to load, the modal shows an infinite loading shimmer with no error feedback, and embedding websites have no way to implement fallback UI, retry logic, or error monitoring.Problem
fetchAsset()insrc/asset/asset-service.tsreturnsundefinedon network errors or non-OK responses (lines 15-19, 67-69). The modal continues showing shimmer placeholders indefinitely.InteractionTracker.createEvent()insrc/modal/interaction-tracker.ts(lines 86-88) logs errors to console but provides no external signal of failure.Proposed Approach
1. Dispatch
capture-eye-errorCustomEvent from the<capture-eye>component2. Dispatch
capture-eye-loadedsuccess event3. Add an
errorstate to the modalInstead of infinite shimmer on fetch failure, show a minimal error state (e.g., "Unable to load asset data") with an optional retry action.
Affected Files
src/asset/asset-service.ts— Error handlers at lines 15-19, 67-69, 85-88, 113-116src/modal/modal-manager.ts— WherefetchAssetresults are consumedsrc/modal/modal.ts— Add error state rendering alongside shimmer/loaded statessrc/capture-eye.ts— Expose events to host applicationsExpected Impact