Move Sidenav keyboard shortcut into Leptos

[JamesbbBriz]

Problem

The Sidenav keyboard shortcut was owned by a globally loaded JavaScript sidecar. That bypassed the Leptos component lifecycle, queried the DOM globally, and required the application shell to load component-specific JavaScript.

What changed

• move Ctrl+B / Cmd+B handling into SidenavWrapper
• update the existing RwSignal<bool> through SidenavContext
• ignore input, textarea, and inherited contenteditable focus targets
• reject Shift/Alt-modified shortcuts and respect an already-handled event
• remove the listener explicitly when its wrapper unmounts
• remove the obsolete sidenav.js file and shell script tag
• use Leptos re-exports for browser bindings and close the registry's Cargo dependency metadata
• add browser coverage for normal shortcuts, editable targets, event arbitration, exact modifiers, and unmount/remount cleanup
• synchronize the distributable registry source and update the changelog

Security impact

No network listeners, telemetry, remote state, permissions, or background data transfer were added. The change removes a globally loaded script and scopes the keyboard handler to the mounted component lifecycle.

Verification

PORT=3000 pnpm --dir e2e exec playwright test tests/components/sidenav.spec.ts --project=chromium --workers=1
# 9 passed

CARGO_ENCODED_RUSTFLAGS=$'-C\x1fsymbol-mangling-version=v0\x1f--cfg\x1ferase_components' cargo +nightly-2026-07-23 test -p registry --lib
# 35 passed

CARGO_ENCODED_RUSTFLAGS=$'-C\x1fsymbol-mangling-version=v0\x1f--cfg\x1ferase_components' cargo +nightly-2026-07-23 test --workspace --lib --bins --tests
# 254 passed

cargo +nightly-2026-07-23 test --bin ui
# 310 passed

CARGO_ENCODED_RUSTFLAGS=$'-C\x1fsymbol-mangling-version=v0\x1f--cfg\x1ferase_components' cargo +nightly-2026-07-23 check -p app --no-default-features --features ssr

CARGO_ENCODED_RUSTFLAGS=$'-C\x1fsymbol-mangling-version=v0\x1f--cfg\x1ferase_components' cargo +nightly-2026-07-23 leptos build

cargo +nightly-2026-07-23 fmt --all -- --check
leptosfmt --check app_crates/registry/src/ui/sidenav.rs
git diff --check

A clean standalone consumer fixture containing the distributed Sidenav source also passes cargo check with the dependencies resolved by ui init plus the registry-declared leptos_router and strum/derive dependencies.

The unrestricted cargo test --workspace reaches two pre-existing leptos_ui doctest failures (void references an undefined url, and one variants example omits the macro import). Both failures are outside this change; all workspace library, binary, integration, and unit tests pass.

Fixture and migration notes

• no storage or data migrations
• no production-like fixtures
• registry Cargo metadata now declares the component's existing compile-time dependencies

Closes #28

[max-wells]

LGTM — clean port of keyboard shortcut into Leptos lifecycle, tests pass, docs/changelog/registry synced.

[max-wells]

Merged — thanks for the clean port and thorough test coverage @JamesbbBriz! 🙌

[JamesbbBriz]

Thanks for the review and merge. I really appreciate it.

I would love to keep contributing to Rust/UI. I think it has a lot of potential for admin and internal products, where a Rust frontend and backend fit naturally.

My next idea is a backend-agnostic SaaS Admin Shell built from the existing components. It would cover responsive navigation, route-aware page chrome, common page states, and a realistic dashboard, while leaving auth, RBAC, tenancy, billing, and database choices to each application.

Most of my work is client delivery, so I want to use this shell in real projects, find the friction, and contribute the fixes upstream. I see the shell as a starting point, not a one-off PR. I hope to keep contributing across the repository, including components, the registry and CLI, and framework-level improvements that make Rust frontend development easier.

My preference is to keep the canonical template in this monorepo and expose it through ui-cli. I also prefer building a sustained, visible contribution history in the main project rather than moving substantial work into a smaller side repository, though I am happy to follow the structure that makes the most sense for Rust/UI.

Would you be open to this? If so, I can open a focused design issue before I start coding.