Log Viewer: Modernize with new @observedFrom decorator

[iOvergaard]

Summary

Spike to modernize the log-viewer package — one of the oldest in the backoffice — by introducing two new Context API primitives and applying them across every context-consuming file.

Builds on top of #22519 (Context API: Defer decorator controller creation to hostConnected — which now also aligns UmbControllerHostMixin with Lit's ReactiveElement pattern). Review that first.

New primitives (in libs/context-api/observe/)

@observedFrom(token, selector, { default }) — accessor/property decorator that binds the decorated property to an observable slice of a context. Combines consume + observe + assign in one declaration.

// Before:
@state() private _logs: LogMessageResponseModel[] = [];
#logViewerContext?: Context;

@consumeContext({ context: UMB_APP_LOG_VIEWER_CONTEXT })
private set _logViewerContext(v) { this.#logViewerContext = v; this.#observeLogs(); }
private get _logViewerContext() { return this.#logViewerContext; }

#observeLogs() {
  this.observe(this._logViewerContext?.logs, (logs) => this._logs = logs ?? []);
}

// After:
@observedFrom(UMB_APP_LOG_VIEWER_CONTEXT, (ctx) => ctx.logs, { default: [] })
@state() private _logs: LogMessageResponseModel[] = [];

this.observeContext(token, selector, callback) — method on UmbClassMixin/UmbElementMixin for side-effect-only observations (no bound value):

this.observeContext(
  UMB_APP_LOG_VIEWER_CONTEXT,
  (ctx) => ctx.filterExpression.pipe(skip(1)),
  () => this._logViewerContext?.getLogs(),
);

Thanks to the mixin refactor in #22519, the decorator registers its UmbContextConsumerController directly via addUmbController — no queueMicrotask deferral, no throwaway wrapper.

Migration: log-viewer

Applied to 11 files across all four pattern categories (simple, paged, complex, manual cleanup):

File	Before	After	Δ
log-search-view.element.ts	107	86	−21
log-viewer-polling-button.element.ts	119	107	−12
log-viewer-date-range-selector.element.ts	116	109	−7
log-viewer-log-level-overview.element.ts	48	37	−11
log-viewer-log-level-filter-menu.element.ts	133	117	−16
log-overview-view.element.ts	171	156	−15
log-viewer-message-templates-overview.element.ts	124	120	−4
log-viewer-saved-searches-overview.element.ts	118	114	−4
log-viewer-messages-list.element.ts	215	191	−24
log-viewer-search-input.element.ts	269	259	−10
log-viewer-log-types-chart.element.ts	252	234	−18
Total	1672	1530	−142

Counting only changed regions (git stat): −241 / +99 across the 11 files.

Each file loses the #ctx / set _ctx / get _ctx / #observe* / individual @state triads. Observable state becomes declarative. Side-effect observations (filter → refetch) move to this.observeContext. Imperative context method calls stay the same.

How @observedFrom works

The decorator wraps UmbContextConsumerController + element.observe(). A stable per-field observer alias keeps subscriptions tidy across context instance changes. When the selector's observable emits undefined (common with asObservablePart((data) => data?.items) over nullable state), the decorator falls back to the declared default — matching the value ?? default defensive pattern consumers previously wrote by hand.

Test plan

• 10 unit tests for @observedFrom and observeContext covering: bind, re-render on emit, default value, late-arriving provider, re-subscription on new provider, unprovide cleanup, default-on-undefined-emission, UmbControllerBase hostConnected-wrapper path
• All 73 existing context-api tests still pass (now 83 with the parent-branch additions)
• Full client test suite: 1472 / 1472 passing
• Manual E2E in browser — Settings → Log Viewer:
  • Overview: time period, error count, log levels, log types chart, saved searches, common messages all render
  • Search: filter input with debounce, log level filter menu, date range, polling toggle, pagination
  • Zero console errors during navigation

What is NOT in this PR (deferred)

Kept scope tight for reviewability. Follow-ups worth picking up:

Log-viewer context-side modernization

• Resolve the "self-providing workspace context" TODO — logviewer-workspace.context.ts currently provides itself under a custom token, which tangles data-fetching + UI-state + URL-sync responsibilities. Either make it a plain global context or integrate properly with the workspace base
• Replace silent .catch(() => {}) with UmbNotificationContext toast feedback on save/delete failures
• Extend UmbRepositoryBase on the log-viewer repository to align with current conventions
• Fix setInterval(...) as unknown as number — window.setInterval returns number in browsers

Next Context API primitive: umbContextObserve Lit directive

For render-only cases where you don't need a class field. The log-viewer still has a couple of these — e.g. log-search-view.element.ts and log-overview-view.element.ts both observe ctx.canShowLogs purely to drive a conditional render:

// Today (with @observedFrom):
@observedFrom(UMB_APP_LOG_VIEWER_CONTEXT, (ctx) => ctx.canShowLogs, { default: true })
@state() private _canShowLogs = true;

render() { return this._canShowLogs ? html`<messages-list>` : html`<too-many-warning>`; }

// With a directive:
render() {
  return umbContextObserve(UMB_APP_LOG_VIEWER_CONTEXT, (ctx) => ctx.canShowLogs, true, (canShow) =>
    canShow ? html`<messages-list>` : html`<too-many-warning>`
  );
}

Shape: Lit AsyncDirective implementing update / disconnected / reconnected. Holds the context consumer and subscription internally, keyed on (host, token, selector reference). Cleans up on any of: observable/selector change, part removal, element disconnect.

@observedFrom is the higher-leverage primitive (usable in render AND derived logic), so the directive is optional sugar — nice to have for the "pure conditional render" pattern.

Other small items

• @observedFrom consumer cache — per-host-per-token sharing. Four @observedFrom fields pointing at the same context currently create four UmbContextConsumerControllers. Not measurable in practice but easy to collapse.
• Shared UmbPageResult<T> — the { items, total } → exposed getters pattern is repeated in the paged views; worth a helper
• CSS token polish — hardcoded colours (#d42054) and sizes (20px, 10px 20px) should move to --uui-* tokens
• Accessibility — role="columnheader" / aria-label on the messages table
• Typing fixes — PropertyValueMap<any> → PropertyValueMap<this>; modal manifest in its own file

🤖 Generated with Claude Code

[nielslyngsoe]

So this adds a controller, to add the controller?

Seems like there is a problem, that this tries to avoid that that should be resolved in other ways?

[nielslyngsoe]

Are you saying this fix some JS flow, so controllers can be added as part of the constructor?

[nielslyngsoe]

I´ve had this particular idea as well, but what held me back from doing it so far have been this problem.

Imagine this case:

`
@observedFrom(UMB_APP_LOG_VIEWER_CONTEXT, (ctx) => ctx.logs, { default: [] })
@State() private _logs: LogMessageResponseModel[] = [];

@observedFrom(UMB_APP_LOG_VIEWER_CONTEXT, (ctx) => ctx.something, { default: [] })
@State() private _something: LogMessageResponseModel[] = [];
`

This would create two Context Consumers, which is a performance problem, Context Consumptions are the heaviest JS task of the application and we need in our code and for Packages code to keep it as low as posible.

So before we can do this, we need to introduce some kind of gathering system/cache/?

A system that makes sure that if there are multiple Consumers, then they utilize the same DOM event.