Update README and future-plans to reflect current state

README: add PDF attachments, maintenance menu, mv-sync build step,
resizable pane, URL-based navigation, word-split search, grid highlights.
future-plans: add render_field_value integrations, field types, PDF paging,
inventory/grid URL state; update state variable list.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-03-22 02:54:14 +00:00
parent 58c93f2bd0
commit 13ab5867c7
2 changed files with 99 additions and 25 deletions

View File

@@ -1,26 +1,25 @@
# Future Plans
## Big refactor: app architecture
## 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`). This is fragile and hard to reason about.
`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.
Something like:
and have `parse_url()` return a new state value rather than mutating globals:
```js
function parse_url(path) {
// returns a state object, touches nothing external
return { section, grid_view_state, current_grid_id, ... };
}
state = parse_url(location.pathname); render(state);
```
Then the caller assigns it: `state = parse_url(location.pathname); render(state);`
### render() if/else chain
The render dispatcher violates stated preferences — long chains of bare `else if`
branches. Replace with a lookup table of arrow functions:
The render dispatcher is a long chain of bare `else if` branches. Replace with a
lookup table:
```js
const SECTION_RENDERERS = {
components: render_components,
@@ -29,14 +28,40 @@ const SECTION_RENDERERS = {
grids: render_grids,
templates: render_templates,
};
function render() {
sync_nav();
SECTION_RENDERERS[section]?.();
}
function render() { sync_nav(); SECTION_RENDERERS[section]?.(); }
```
### General module structure
As the app grows, `app.mjs` is becoming a monolith. Consider splitting into
per-section modules (e.g. `views/components.mjs`, `views/grids.mjs`) that each
export their render function and own their local state.
### 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
### Field rendering integrations
`render_field_value()` in `app.mjs` is the central place for field display logic.
Planned extensions:
- Mouser/Digi-Key part number fields → auto-craft links to product pages
- More URL-like patterns (without `https://` prefix)
### Field types
Currently all field values are free-text strings. Could benefit from typed fields
(numeric, enum/dropdown) for better formatting and validation.
## 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.