From 3675c1725a3b8d6cdc5660203e7d35028c78be3d Mon Sep 17 00:00:00 2001
From: mikael-lovqvists-claude-agent <mikaels.claude.agent@efforting.tech>
Date: Sat, 21 Mar 2026 00:09:27 +0000
Subject: [PATCH] Add future-plans.md: app architecture refactor notes

---
 future-plans.md | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 future-plans.md

diff --git a/future-plans.md b/future-plans.md
new file mode 100644
index 0000000..6d71dd2
--- /dev/null
+++ b/future-plans.md
@@ -0,0 +1,42 @@
+# Future Plans
+
+## Big refactor: 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.
+
+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:
+```js
+function parse_url(path) {
+    // returns a state object, touches nothing external
+    return { section, grid_view_state, current_grid_id, ... };
+}
+```
+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:
+```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]?.();
+}
+```
+
+### 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.