Skip to content

feat(runtime): log JSX view-construction errors via sap/base/Log - #11

Closed
petermuessig wants to merge 1 commit into
mainfrom
feat/log-view-errors
Closed

petermuessig wants to merge 1 commit into
mainfrom
feat/log-view-errors

Conversation

@petermuessig

Copy link
Copy Markdown
Member

Summary

  • installViewScopeBridge.ts: patches View.prototype.onControllerConnected (instead of createContent, which subclass dynamic dispatch bypasses) to install a per-instance wrapper on this.createContent. The wrapper: opens the JSX scope (withScope), calls Log.error on any sync throw or async rejection, then re-throws/re-rejects so propagation is unchanged. The instance own-property is deleted in a finally block.
  • ExploreSample.tsx: adds Log.error in both catch handlers (demo-view load failure and docs-load failure) so the exact user-facing message is traceable in the UI5 log.
  • QUnit tests (runtime/view-error-logging.qunit.ts): two regression tests verify sync-throw and async-reject paths — Log.error called exactly once with the right message/component id, and View.create still rejects.
  • Also brings runtime/forwarded-aggregation.qunit.ts from fix/forwarded-aggregation-issue-9 (was missing on main; needed for the testsuite entry already added there).

Why patch onControllerConnected, not createContent

UI5's onControllerConnected calls this.createContent(e), which dynamically dispatches to the subclass prototype. Patching View.prototype.createContent only intercepts code that explicitly calls super.createContent() — no View subclass does that (the base method is a no-op). By patching onControllerConnected instead, we install a per-instance own-property that shadows both the subclass prototype and View.prototype, so every call path — including runWithPreprocessors — routes through our wrapper.

Test plan

  • cd packages/jsx-runtime && npm test — all 12 test modules green (47 total), including runtime/view-error-logging 🧪 2/2
  • tsc --noEmit clean, eslint clean
  • Changeset present: .changeset/log-view-errors.md (patch bump for @ui5-community/jsx-runtime)

Previously, when a JSX view's createContent() threw (sync or async),
the error propagated as a rejected Promise but was never written to
the UI5 Log. In the showcase it was only rendered as a text control,
invisible to log-scraping tooling and sap-ui-log-level debugging.

The fix patches View.prototype.onControllerConnected (not createContent,
which is bypassed by subclass dynamic dispatch) to install a per-instance
wrapper on this.createContent before calling the original method. The
wrapper opens the JSX scope (withScope), wraps the subclass call in
try/catch plus .catch() for async, calls Log.error on failure, then
re-throws — preserving all existing propagation behaviour.

The instance own-property is deleted in a finally block so the
prototype chain is fully restored after each view construction.

ExploreSample.tsx also adds Log.error calls in both its catch handlers
(demo-view load failure and docs-load failure) so the exact user-facing
message is traceable in the log.

Two QUnit regression tests verify both the sync-throw and async-reject
paths: Log.error is called exactly once with the right message and
component id, and View.create still rejects.

Also brings runtime/forwarded-aggregation.qunit.ts from the
fix/forwarded-aggregation-issue-9 branch (was missing on main).
@petermuessig

Copy link
Copy Markdown
Member Author

Superseded by #10, which now includes this change. The feat/log-view-errors commit (04f7ae3) was rebased as the first commit on fix/forwarded-aggregation-issue-9, so the logging work and the forwarding fix ship together in PR #10. The feat/log-view-errors branch is left intact on the remote.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant