## What changed Replaced `VueJsonPretty` (`vue-json-pretty`) with `CodeQueryEditor.vue` (Monaco-based) for JSON rendering in `LLMContentRenderer.vue`. Inlined the `MessageItem` sub-component directly into the template with `CodeQueryEditor` for JSON message content. Added `showLineNumbers` and `stickyScroll` props to `CodeQueryEditor`. Removed the unused `vue-json-pretty` dependency from `package.json`. Passed unique editor IDs from `TraceDetailsSidebar` via a new `instanceId` prop to prevent Monaco editor ID collisions. ## Why `vue-json-pretty` formats the entire JSON tree on initial render, causing lag on long JSON payloads. Monaco (via `CodeQueryEditor`) renders only visible viewport lines, making performance O(visible) instead of O(total). ## Approach - Replaced all 7 `VueJsonPretty` instances in `LLMContentRenderer.vue` with `<CodeQueryEditor>` in read-only mode (`:read-only="true"`, `:show-line-numbers="false"`, `:sticky-scroll="false"`) - Inlined the `MessageItem` sub-component as a `v-for` block with `CodeQueryEditor` for JSON message content and the existing `v-html` markdown renderer for non-JSON content - Converted the component to `<script setup lang="ts">` with `defineAsyncComponent` for `CodeQueryEditor` - Added `showLineNumbers` and `stickyScroll` props (both default `true`) to `CodeQueryEditor.vue` to support the JSON viewer use case - Added a `watch` on `showLineNumbers` to dynamically toggle line numbers in Monaco - Passed `instanceId` from `TraceDetailsSidebar` down to `LLMContentRenderer` to generate unique editor IDs like `trace-id-msg-json-editor-0` ## Considered & rejected - **Render function approach with synchronous import of CodeQueryEditor** — rejected because it forced manual editor height computation and module-level counters for editor IDs. Inlining `MessageItem` as a template component was cleaner and consistent with the other 5 template `CodeQueryEditor` locations. - **Retaining `MessageItem` as a separate component with render function** — rejected because the render function approach was over-engineering for what is now a simple `v-for` with conditional `CodeQueryEditor` / markdown branching. ## Risk Medium. Monaco editor initialization has non-trivial overhead; rendering multiple editors on one page (e.g., many messages in a conversation) could impact initial render time. Reviewers should check that the `instanceId` prop is correctly wired from `TraceDetailsSidebar` to avoid duplicate Monaco editor IDs, and that the `tw:h-full` class application on content-wrapper divs doesn't break non-JSON (plain text / markdown) layouts.
web
This template should help get you started developing with Vue 3 in Vite.
Recommended IDE Setup
VSCode + Volar (and disable Vetur) + TypeScript Vue Plugin (Volar).
Type Support for .vue Imports in TS
TypeScript cannot handle type information for .vue imports by default, so we replace the tsc CLI with vue-tsc for type checking. In editors, we need TypeScript Vue Plugin (Volar) to make the TypeScript language service aware of .vue types.
If the standalone TypeScript plugin doesn't feel fast enough to you, Volar has also implemented a Take Over Mode that is more performant. You can enable it by the following steps:
- Disable the built-in TypeScript Extension
- Run
Extensions: Show Built-in Extensionsfrom VSCode's command palette - Find
TypeScript and JavaScript Language Features, right click and selectDisable (Workspace)
- Run
- Reload the VSCode window by running
Developer: Reload Windowfrom the command palette.
Customize configuration
See Vite Configuration Reference.
Project Setup
npm install
Compile and Hot-Reload for Development
For stand-alone UI development environment, create .env file and which contains below environment variable
VITE_OPENOBSERVE_ENDPOINT=http://localhost:5080/
npm run dev
Type-Check, Compile and Minify for Production
npm run build
Run Unit Tests with Vitest
npm run test:unit
Run End-to-End Tests with Cypress
npm run test:e2e:dev
This runs the end-to-end tests against the Vite development server. It is much faster than the production build.
But it's still recommended to test the production build with test:e2e before deploying (e.g. in CI environments):
npm run build
npm run test:e2e
Lint with ESLint
npm run lint