From a6bd340d81aa201f4d3b784c9e885da4298b1f36 Mon Sep 17 00:00:00 2001
From: mikael-lovqvists-claude-agent <mikaels.claude.agent@efforting.tech>
Date: Mon, 23 Mar 2026 23:51:56 +0000
Subject: [PATCH] future-plans: rich return values from templates (slots, not
 just strings)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
---
 future-plans.md | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/future-plans.md b/future-plans.md
index 3517b89..55cd8b0 100644
--- a/future-plans.md
+++ b/future-plans.md
@@ -222,6 +222,28 @@ views, field parsers, etc.) should use a CodeMirror 6 editor instead of a plain
 `<textarea>`. Gives syntax highlighting, bracket matching, and a proper editing
 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:
+
+- 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 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).
+
+This also applies to field parsers and custom search views once those exist.
+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
+experience for JS snippets.
+
 ## Search & views
 
 ### Custom search views