mikael-lovqvists-claude-agent/electronics-inventory
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

future-plans: unified formatter→renderer pipeline and terminology revision

Browse Source 
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
mikael-lovqvists-claude-agent
2026-03-23 23:53:53 +00:00
parent a6bd340d81
commit 5ac980c9fa
1 changed files with 22 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
future-plans.md
View File

@@ -224,21 +224,31 @@ experience for JS snippets.
## Template system
### Rich return values from templates
Currently formatters can only return a plain string. It would be useful to return
richer output — e.g. styled text, multiple values, or structured data. Options:
### Unified formatter → template pipeline and terminology revision
The current system conflates several distinct concepts under the word "template",
creating ambiguity:
- Return an object with named slots: `{ label: "100kΩ", sublabel: "0603", badge: "low stock" }`
which the renderer maps to specific DOM locations
- Return an HTML string rendered via `innerHTML` (simple but XSS risk if data is
user-controlled, and ties templates to DOM structure)
- Return a DOM node or a lightweight virtual-DOM descriptor
- The HTML `<template>` elements used for UI cloning (internal, not user-facing)
- The user-written JS formatter functions (currently called "templates" in the UI)
- The future idea of user-defined DOM rendering templates
The object-with-slots approach is probably the right default — it keeps templates
declarative, avoids XSS, and lets the UI decide how to present each slot. Slots
could vary by context (list row vs detail header vs dropdown item).
Proposed clearer terminology:
- **Formatter** — a user-written JS function that receives a component and returns a
structured record (named slots), e.g. `{ label, sublabel, badge, ... }`
- **Renderer** — a DOM fragment template (possibly user-defined) that consumes a
formatter's record and produces the visual output for a given context (list row,
detail header, dropdown item, etc.)
- **View template** — the internal HTML `<template>` cloning mechanism (keep as-is,
but don't expose this term to users)
This also applies to field parsers and custom search views once those exist.
The pipeline becomes: `component → formatter → record → renderer → DOM`. Formatters
and renderers are decoupled — the same formatter record can feed different renderers
in different contexts. Users can define custom renderers (DOM fragments with named
slot targets) in addition to custom formatters.
This revision also applies to field parsers and search view expressions once those
exist — they all follow the same pattern of JS function → structured output →
context-specific renderer.
Any field that accepts JavaScript (name formatter templates, future custom search
views, field parsers, etc.) should use a CodeMirror 6 editor instead of a plain
`<textarea>`. Gives syntax highlighting, bracket matching, and a proper editing