[Feature] Pseudo-HMR (Hot Module Replacement) via Session Storage

[HaHiepThanh]

📋 Context & Problem Description

Because WebAssembly is a compiled binary target, implementing true Hot Module Replacement (HMR) (which dynamically patches active JavaScript memory states on file change, like Vite or Webpack) is highly challenging.

Currently, during development, Gutter developers must rebuild the WASM target and reload the browser page. This reload wipes out all in-memory application states (e.g., partially filled forms, active tabs, toggle states), creating a slow developer feedback loop (DX).

💡 Proposed Solution & Implementation Plan

We propose introducing a Pseudo-HMR mechanism that preserves state across page reloads:

1. State Serialization:
   Provide a mechanism in Gutter runtime where the root Element tree can serialize its active state tree into a structured JSON string.
2. Dev Reload Watcher:
   In development mode (gutter run), CLI establishes a WebSocket connection to the browser client. On file change:
   • CLI triggers a background build of the WASM file.
   • CLI sends a "will-reload" signal to the client.
   • The client intercepts this signal, serializes the active widget state tree, and saves it into sessionStorage.
   • The browser is then commanded to reload.
3. State Restoration:
   On startup, Gutter checks if sessionStorage contains a serialized state tree from a prior hot reload. If found:
   • During component mounting or hydration, Gutter restores the states into corresponding stateful elements by path/index alignment.
   • Clear the storage after restoration.

🎯 Impact & Benefits

• Fast Developer Loop: Developers can modify Go files and see updates instantly without losing form inputs or current navigation paths.
• Modern Parity: Brings Go-WASM DX closer to JS frameworks.

🏷️ Suggested Labels

feature, cli, dx