# Future Plans

## App architecture

### parse_url mutates too many module-level variables
`parse_url()` directly assigns to a large number of module-level state variables
(`section`, `grid_view_state`, `grid_tab`, `current_grid_id`, `grid_draft`,
`current_panel_idx`, `grid_source_id`, `highlight_cell`, `selected_component_id`).
This is fragile and hard to reason about.

Preferred direction: represent the full UI state as a single immutable state object,
and have `parse_url()` return a new state value rather than mutating globals:
```js
function parse_url(path) {
    return { section, grid_view_state, current_grid_id, ... };
}
state = parse_url(location.pathname); render(state);
```

### render() if/else chain
The render dispatcher is a long chain of bare `else if` branches. Replace with a
lookup table:
```js
const SECTION_RENDERERS = {
    components: render_components,
    inventory:  render_inventory,
    fields:     render_fields,
    grids:      render_grids,
    templates:  render_templates,
};
function render() { sync_nav(); SECTION_RENDERERS[section]?.(); }
```

### app.mjs monolith
`app.mjs` is large. Consider splitting into per-section modules
(`views/components.mjs`, `views/grids.mjs`, etc.) that each export their render
function and own their local state.

## Field system

### Improvements

#### 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
- More URL-like patterns (without `https://` prefix)

### Long term

#### 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 page count and multi-page navigation
Currently only the first page thumbnail is shown. Could show page count and allow
browsing pages in the lightbox.

## Inventory

### Inventory URL reflects selected entry
Similar to how components now reflect `/components/:id` in the URL, inventory
entries have no URL state — refreshing loses context.

## Grids

### Grid URL state
Navigating into a grid viewer updates the URL correctly, but the grid list and
draft state have no URL representation.