110 lines
4.1 KiB
Markdown
110 lines
4.1 KiB
Markdown
# Future Plans
|
|
|
|
## KV store
|
|
|
|
### Extract into shared library
|
|
`kv-store.mjs` is already copied into at least 3 projects (`electronics-inventory`,
|
|
`fs-views`, `publication-tool`). Should live in its own Gitea repo as an installable
|
|
npm package (`npm install git+https://...`) so changes propagate rather than drift.
|
|
|
|
### Delta / revision tracking
|
|
Add a delta log alongside the main snapshot file (e.g. `inventory.ndjson.deltas`)
|
|
that records every `set`/`delete` as a timestamped entry. The main file stays a
|
|
clean current-state snapshot; the delta file accumulates the full history. Enables
|
|
undo, audit trails, and debugging data corruption.
|
|
|
|
## 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
|
|
|
|
### File picker search filter
|
|
The file picker dialog has no search/filter input. With many datasheets this becomes
|
|
unwieldy. Add a filter input at the top of the list that narrows by display name and
|
|
filename.
|
|
|
|
### 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.
|