Add feed sidebar navigation #8
Loading…
Reference in a new issue
No description provided.
Delete branch "worktree-feed-sidebar-nav"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
dioxus-primitivescomponents (Sidebar, Button, Badge, ScrollArea, etc.) rather than raw elementslist_ranked_articles(feed_id)db::articlesunit tests covering the newfeed_idfilter (no filter / filter / score ordering)Fixes along the way
#[css_module]class hashing made a handwritten selector target nothing)<main>wrapper insideSidebarInset, which already renders its own<main>)Test plan
cargo test --workspace --exclude feedsignal-webcargo clippy(server + web + wasm feature sets) cleancargo fmt --checkdx serveinstance: feed switching, subscribe form, article row layout, and list scrolling all confirmed via DOM inspection, not just visuallyArticles past the first screenful were unreachable — not clipped by accident, genuinely inaccessible, since the page itself couldn't scroll either (the sidebar wrapper is overflow: hidden by design, so the intended scroll boundary is internal to the main content pane). Root cause: SidebarInset already renders a <main> (class dx-sidebar-inset, a properly height-bound flex column — main{ height:900px in a 900px viewport, flex-direction:column}), but I'd also written an explicit `main { ... }` as ITS child, producing a `<main><main>...</main></main>` (confirmed via a headless Playwright probe against the live dev server, not just DevTools guesswork). The inner <main> is just a plain flex item with the default flex: 0 1 auto, so it sized to its own content (6500+px) instead of being constrained by the outer one's box, and the ScrollArea inside it had nothing bounded to scroll within. Removed the redundant inner <main> — SidebarInset's children (the content-header div and ScrollArea) now sit directly in its own <main>, which is the actual flex column that needs to size them. Also pinned ScrollArea's direction to Vertical (it defaults to Both, which was adding an unnecessary horizontal scrollbar) and moved the sizing rule in app.css off a class ScrollArea silently drops (confirmed via the same probe — a caller-supplied `class` never reaches ScrollArea's rendered DOM, only its own internal one does) onto its stable data-scroll-direction attribute instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PqTJmazHBQK878vjQ4JnnF