Feature/add error boundary component for ontology editor #129

[dustintnguyen]

Description

Related Issue(s)

Closes #

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (code improvements without changing functionality)
• Documentation update
• Performance improvement
• Test addition/improvement
• CI/CD or build process change

Changes Made

-add reusable [ErrorBoundary] component
-add ontology-specific fallback UI with retry action
-wrap main editor page to prevent full app crashes
-add tests for fallback and recovery behavior

Screenshots/Recordings (if applicable)

Testing

-Open [details-panel.tsx]
-Add a temporary throw at the top of [DetailsPanel()]:
throw new Error('QA test error')
-Save the file and reload the page.
-Confirm the error boundary fallback appears instead of the full app crashing.
-Remove the temporary [throw new Error('QA test error')] line.
-Save again.
-Click Try again and confirm the editor recovers.

Test Plan

• Unit tests added/updated
• Integration tests added/updated
• E2E tests added/updated
• Manual testing completed
• Tested on multiple browsers (Chrome, Firefox, Safari, Edge)
• Tested on different screen sizes

How to Test

1. Start the app and open the ontology editor.
   2.Confirm the editor loads normally:
   -header is visible
   -left navigation is visible
   -details/graph area renders
   -stats panel renders
2. Trigger a runtime error inside the editor tree.
   -easiest QA method: temporarily make a child component throw, for example in [details-panel.tsx], then reload.
3. Verify the app does not fully crash.
4. Verify the fallback UI appears with:
   -“Something went wrong”
   -the error message
   -a “Try again” button
5. Remove the forced error or make the component safe again.
6. Click “Try again”.
7. Verify the ontology editor renders again without a page refresh.
8. Switch between Details View and Graph View in [page.tsx] and confirm normal behavior still works.
9. Confirm no unrelated layout regressions in header, navigation, main panel, and stats panel.

Performance Impact

• No performance impact
• Performance improved (describe how)
• Potential performance concerns (describe and explain why acceptable)

Performance measurements (if applicable):

Accessibility

• Keyboard navigation works correctly
• Screen reader tested
• Color contrast meets WCAG 2.1 AA standards
• ARIA labels added where necessary
• Focus management implemented correctly
• Not applicable (no UI changes)

Code Quality Checklist

• Code follows project style guidelines (ESLint/Prettier)
• Self-review completed
• Comments added for complex logic
• No unnecessary console.log or debug code
• No hardcoded values (uses constants/config)
• Error handling implemented appropriately
• TypeScript types are properly defined (no any unless justified)
• Code is DRY (Don't Repeat Yourself)

Documentation

• README updated (if needed)
• API documentation updated (if applicable)
• Inline code comments added for complex logic
• ROADMAP.md updated (if applicable)
• CHANGELOG updated (if applicable)

Dependencies

• No new dependencies added
• New dependencies added (list below with justification)

New dependencies (if any):

Breaking Changes

• No breaking changes
• Breaking changes (describe below)

Migration guide (if applicable):

Deployment Notes

• No special deployment steps required
• Requires environment variable changes (list below)
• Requires database migration
• Requires cache clearing
• Other deployment considerations (describe below)

Deployment instructions (if applicable):

Security Considerations

• No security implications
• Input validation added/verified
• XSS prevention measures in place
• CSRF protection verified
• Authentication/authorization checked
• No sensitive data exposed in logs/errors
• Dependencies scanned for vulnerabilities

Rollback Plan

If roll back is needed, roll back to commits from branch.

Additional Context

Reviewer Checklist

• Code changes reviewed
• Tests reviewed and passing
• Documentation reviewed
• No obvious security issues
• Performance impact acceptable
• Accessibility requirements met
• Breaking changes justified and documented

---

Generated with Claude Code

Co-Authored-By: Claude Sonnet 4.5 noreply@anthropic.com

[charulata871]

Hey,
I went through the changes and overall this is a really solid addition. Introducing an ErrorBoundary for the ontology editor is a great step—it makes the app much more resilient by preventing full crashes and keeping failures contained to the editor section.

I especially liked:

The reusable design of the ErrorBoundary
The fallback UI with the “Try again” action — feels smooth and user-friendly
Good test coverage, particularly around error handling and recovery flow

• A few things to improve:
  In page.tsx, there seems to be duplicate layout rendering (header, main layout, panels repeated inside the ErrorBoundary). This could lead to unnecessary rendering and should be cleaned up.
  There also appears to be a duplicate rendering of the main content (DetailsPanel / GraphView), which might cause unintended UI behavior.
  Using console.error in componentDidCatch is fine for now, but in the future it would be better to integrate a proper logging/monitoring solution.
  The fallback currently shows the raw error message — might be worth sanitizing it slightly for a better user-facing experience.

Overall

The feature is well implemented, tests are meaningful, and it clearly improves the robustness of the editor. Just a few small cleanups needed.

LGTM 👍 (with minor suggestions)

[charulata871]

Hey,
I went through the changes and overall this is a really solid addition. Introducing an ErrorBoundary for the ontology editor is a great step—it makes the app much more resilient by preventing full crashes and keeping failures contained to the editor section.
I especially liked:

The reusable design of the ErrorBoundary
The fallback UI with the “Try again” action — feels smooth and user-friendly
Good test coverage, particularly around error handling and recovery flow

• A few things to improve:
  In page.tsx, there seems to be duplicate layout rendering (header, main layout, panels repeated inside the ErrorBoundary). This could lead to unnecessary rendering and should be cleaned up.
  There also appears to be a duplicate rendering of the main content (DetailsPanel / GraphView), which might cause unintended UI behavior.
  Using console.error in componentDidCatch is fine for now, but in the future it would be better to integrate a proper logging/monitoring solution.
  The fallback currently shows the raw error message — might be worth sanitizing it slightly for a better user-facing experience.
  -Overall

The feature is well implemented, tests are meaningful, and it clearly improves the robustness of the editor. Just a few small cleanups needed.

LGTM 👍 (with minor suggestions)

[charulata871]

Thanks for the update!

Since there’s a merge conflict in page.tsx, just to confirm — we should keep the newer ErrorBoundary implementation from this branch (@/components/error-boundary) and remove the older default import to avoid duplication.

Also, the ErrorBoundary wrapper added here should be preserved, as it’s the core improvement of this PR.

Once the conflict is resolved and duplicate layout/content rendering is cleaned up, this should be good to merge.

Happy to re-review after the fix 👍