future-plans: add field value parser chain and long-term cache note
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -38,15 +38,39 @@ function and own their local state.
|
|||||||
|
|
||||||
## Field system
|
## Field system
|
||||||
|
|
||||||
### Field rendering integrations
|
### Improvements
|
||||||
`render_field_value()` in `app.mjs` is the central place for field display logic.
|
|
||||||
Planned extensions:
|
#### Field value parser chain
|
||||||
|
Similar to how name formatters use a template chain, field values could be passed
|
||||||
|
through a parser chain that returns structured data based on field name/type hints.
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
- A field whose name contains `tolerance` could parse `20` as `{ negative: 20, positive: 20 }`
|
||||||
|
and `-10/+30` as `{ negative: 10, positive: 30 }`
|
||||||
|
- URL detection (currently hardcoded in `render_field_value()`) could be one parser
|
||||||
|
in this chain rather than a special case
|
||||||
|
- Mouser/Digi-Key part numbers could be detected and return a structured link target
|
||||||
|
|
||||||
|
The parser chain would mirror the template system: user-defined or built-in parsers
|
||||||
|
keyed by field name pattern, tried in order, returning structured data or `null` to
|
||||||
|
pass through to the next. `render_field_value()` would then receive parsed data and
|
||||||
|
render accordingly.
|
||||||
|
|
||||||
|
#### Field rendering integrations
|
||||||
|
With or without a parser chain, `render_field_value()` should gain:
|
||||||
- Mouser/Digi-Key part number fields → auto-craft links to product pages
|
- Mouser/Digi-Key part number fields → auto-craft links to product pages
|
||||||
- More URL-like patterns (without `https://` prefix)
|
- More URL-like patterns (without `https://` prefix)
|
||||||
|
|
||||||
### Field types
|
### Long term
|
||||||
Currently all field values are free-text strings. Could benefit from typed fields
|
|
||||||
(numeric, enum/dropdown) for better formatting and validation.
|
#### 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
|
||||||
|
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.
|
||||||
|
|
||||||
## PDF / files
|
## PDF / files
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user