From 98190c52710d4ce952e4b83238a38adf3d670d01 Mon Sep 17 00:00:00 2001 From: mikael-lovqvists-claude-agent Date: Sun, 22 Mar 2026 15:01:08 +0000 Subject: [PATCH] future-plans: parametric search, field filter, field grouping, DRY audit Co-Authored-By: Claude Sonnet 4.6 --- future-plans.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/future-plans.md b/future-plans.md index fe67e31..eca64ec 100644 --- a/future-plans.md +++ b/future-plans.md @@ -49,6 +49,19 @@ function render() { sync_nav(); SECTION_RENDERERS[section]?.(); } (`views/components.mjs`, `views/grids.mjs`, etc.) that each export their render function and own their local state. +### DRY / SSoT audit +As the app grows, patterns are being duplicated rather than centralized. Areas to +review: +- Field sorting: same sort-by-name logic appears in both detail view and edit dialog +- Field rendering: `render_field_value()` exists but call sites still sometimes + inline display logic +- Component display name: `component_display_name()` is the SSoT but there may be + call sites that still use `c.name` directly +- Server-side: PDF conflict checks, sanitize calls, and rename logic are inline in + route handlers — could be extracted into a `pdf_service` helper +- General pass to identify and eliminate copy-paste between routes and between + render functions before the codebase grows further + ## Field system ### Improvements @@ -79,8 +92,30 @@ With or without a parser chain, `render_field_value()` should gain: - Mouser/Digi-Key part number fields → auto-craft links to product pages - More URL-like patterns (without `https://` prefix) +#### Field selector filter +When adding a field to a component in the edit dialog, the dropdown becomes +unwieldy with many fields. Add a filter/search input to the field selector. + +#### Parametric search +Allow searching/filtering components by field values, not just names. Examples: +- `resistance < 10k`, `package = 0603`, `voltage_rating >= 50` +- Cross-field queries: find all 0603 resistors under 10kΩ +- Should integrate with the existing word-split search or replace it with a + richer query language +- Depends on field types (numeric vs string) for range queries to work correctly + ### Long term +#### Field grouping / linkage +Some fields naturally belong together (e.g. `frequency_stability` and +`frequency_stability_temp_range`). Options: +- Soft linkage: tag fields with a group name, display grouped in the UI +- Structured fields: a field can be a record type with named sub-fields + (e.g. `stability: { value: 10, unit: "ppm", temp_low: -40, temp_high: 85 }`) + +Structured records are the more powerful option but require a schema system and +more complex UI. Grouping/linkage is a lighter short-term win. + #### Renderer/parser result cache Once parsers and formatters run per-render, a cache keyed on field value + template version would avoid redundant work on large inventories. Invalidated when any @@ -89,6 +124,7 @@ template changes. Not urgent — premature until the parser chain exists. #### Field types Currently all field values are free-text strings. Typed fields (numeric, enum/dropdown) would enable better formatting, validation, and range-aware search. +Prerequisite for parametric search with range operators. ## PDF / files