frontend goes vroom

[patrickelectric]

Helps #4434

Improve:

• zenoh page
• one_more_time leaks
  • ping page
  • main page
  • backend status
  • wizard
• decrease video overview update rate (from 1s to 5s)

Results:

[github-actions]

Automated PR Review

0. Summary

• Verdict: MINOR SUGGESTIONS ✏️

Fixes a memory leak in several Vue components that were using the arrow-function data: () => ({...}) form with disposeWith: this, where this did not point at the component instance and OneMoreTime therefore never got disposed. Also adds requestAnimationFrame batching + markRaw to ZenohInspector, drops VideoOverview polling from 1 s to 5 s, and adds a runtime warning in OneMoreTime when disposeWith is not a real component instance.

1. Correctness & Implementation Bugs

• 1.1 [minor] core/frontend/src/components/wizard/DefaultParamLoader.vue:116 — same bug the PR is fixing elsewhere is still present here: data: () => ({ ..., fetch_current_board_task: new OneMoreTime({ delay: 10000, disposeWith: this }) }). With the arrow form, this is the module scope, so _isDestroyed is never observed and the task leaks for the lifetime of the tab. The new console.warn you added in one-more-time.ts will actually fire on this file at runtime — worth folding it into the same PR so the warning shipped with this PR doesn't yell about a leak the PR doesn't fix.

4. Performance

• 4.1 [nit] core/frontend/src/components/zenoh-inspector/ZenohInspector.vue:257-ish — the batching path is a real improvement, but note that this.$set(this.messages, topic, batch[topic]) inside flushStagedMessages still fires one reactive write per topic per frame. If the frame contains many new topics the resulting re-render can still dominate; a future optimization would be to swap this.messages for a new object once per flush (single reactive write) rather than N $set calls. Non-blocking, just a follow-up idea.

6. Code Quality & Style

• 6.1 [nit] core/frontend/src/one-more-time.ts:41 — narrowing disposeWith?: unknown to disposeWith?: { _isDestroyed?: boolean } is a nice targeted type, but it happens to be structurally satisfied by lots of non-Vue objects (anything without _isDestroyed, or with an _isDestroyed typed as boolean | undefined, matches). If you want the compiler — not just console.warn — to catch bad call sites, a nominal marker (ComponentPublicInstance from vue, or a branded type) would do it. Optional.
• 6.2 [nit] core/frontend/src/components/zenoh-inspector/ZenohInspector.vue:247 — isKnownTopic now checks messages and topic_liveliness but not topics itself. That's fine given the current flow (every entry in topics is also in one of those two maps), but the invariant is implicit; a one-line comment on isKnownTopic calling that out would save the next reader some head-scratching.

8. Documentation

• 8.1 [nit] The three inline comments on staging in ZenohInspector.vue (markRaw, keyed by topic, null-prototype) are exactly the kind of "why" that AGENTS.md asks for — good. Same for the "before $set fills the map isKnownTopic reads" comment in the liveliness callback: it directly explains the load-bearing reordering. Nothing to change, just calling it out so it doesn't get "cleaned up" later.

Generated by PR Review Bot. This is advisory, a human reviewer must still approve.