thesysdev/openui

Summary The Vue chat example tells the model that TextContent supports markdown, but the local Vue renderer displays markdown markers literally. Observed while running PR #629 locally, but this appears to be an example/component-library mismatch rather than part of the PR's packages/vue-lang query/mutation scope. Repro Run examples/vue-chat. Ask for a response likely to include formatted text, for example stock information. The assistant response renders literal markdown such as **NVDA** and **$877.33** instead of bold text. Expected Markdown inside TextContent("...") should render as formatted text, or the Vue chat prompt/library should not claim markdown support. Actual Markdown is shown literally. Relevant code examples/vue-chat/lib/library.ts describes TextContent as: "Displays a block of text. Supports markdown formatting within the string." examples/vue-chat/lib/library.ts also instructs: "Use TextContent for all text output. You can use markdown within the text string." examp

Summary @openuidev/[email protected]'s Renderer can crash the host app with a React commit-phase error while re-rendering or streaming content: NotFoundError: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node. The error is thrown deep in React's commit (mutation) phase, so it cannot be caught by a nested error boundary in the host app — it escalates to the app root and unmounts the whole subtree. We hit it in production in a streaming chat UI, and also when a sibling re-render forces an already-rendered Renderer subtree to re-render. Root cause Two interacting behaviors in the renderer (line refs from the published dist/index.mjs, v0.2.1): 1. ElementErrorBoundary re-presents stale children on error. On hasError, render() returns this.lastValidChildren — React element objects captured from a previous render (componentDidMount/componentDidUpdate stash this.props.children). Those elements correspond to DOM node

Is your feature request related to a problem? Please describe. When working with OpenUI responses it is beneficial to have a toMarkdown method for easier debuggability and/or storage for offline improvements. Since LLMs can handle markdown responses better than OpenUI responses it would be beneficial to have an easier way to convert OpenUI responses to markdown Describe the solution you'd like A simple toMarkdown() method on OpenUI responses that recursively parses the response and converts it to plaintext/markdown by stripping away the UI methods Describe alternatives you've considered We can manually implement this today by sending response back to a LLM and stripping away the UI format but this should be doable without needing a separate call Additional context n/a

Currently there is no way to fully validate the openui lang, invalid lines are just silently skipped. https://github.com/thesysdev/openui/blob/main/packages/lang-core/src/parser/statements.ts#L70 Invalid lines (no =, or no identifier) are silently skipped. Example LLM output: Here is the response: root = Stack([TextContent("hi")]) Rendered output: hi The Here is the response: is just silently skipped and parser also returns 0 errors. Maybe add parse(input, strict: true) or something like that to get all the errors. Current workaround: const parser = createParser(schema) const result = parser.parse(input) const lines = input.split("\n") for (let i = 0; i < lines.length; i++) { const trimmed = lines[i].trim() if (!trimmed) continue if (/^[A-Za-z_$][\w$]*\s*=/.test(trimmed)) break const snippet = trimmed.length > 80 ? trimmed.slice(0, 80) + "..." : trimmed result.meta.errors.push({ source: "parser", code: "parse-failed", message: `Line ${i + 1}: "${snippet}"

Summary packages/react-ui/src/components/ChartsV2 currently contains only ARCHITECTURE.md. The document describes implementation details, tests, and utilities for ChartsV2, but there is no implementation in that directory. This can confuse contributors trying to understand the current chart code. Suggested implementation Decide whether this document is still useful as a proposal/historical note. Then either: move it to a more appropriate docs/proposals location, update the title and contents to clearly mark it as historical/proposed architecture, or remove it if it is obsolete. Acceptance criteria Contributors can tell whether ChartsV2 is current, planned, or obsolete. Any stale statements about existing files/tests are corrected or removed. The current chart implementation remains documented where appropriate.