From 5ac980c9fa8ca71dbb4edd33b84408fbf850496b Mon Sep 17 00:00:00 2001
From: mikael-lovqvists-claude-agent <mikaels.claude.agent@efforting.tech>
Date: Mon, 23 Mar 2026 23:53:53 +0000
Subject: [PATCH] =?UTF-8?q?future-plans:=20unified=20formatter=E2=86=92ren?=
 =?UTF-8?q?derer=20pipeline=20and=20terminology=20revision?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

diff --git a/future-plans.md b/future-plans.md
index 55cd8b0..586cd06 100644
--- a/future-plans.md
+++ b/future-plans.md
@@ -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