Responsive Shell (Phase 1 of "make the site responsive") — Design Spec

Context: this is a sub-project

The user's original ask was "ทำหน้าเว็บทั้งหมดให้ responsive" (make the whole site responsive). The app has no responsive/breakpoint infrastructure at all today, and spans hundreds of routes (navigator.ts is ~3,800 lines) built around wide, dense data tables (table-excel, horizontal drag-scroll) and multi-column filter forms. Doing "everything" in one pass isn't tractable, so this work is split into phases:

Phase 1 (this spec): the global shell — sidebar, toolbar, main content container — since it's present on every page and is the highest-leverage, lowest-risk piece.
Later phases (separate specs, not started): per-page table and form responsiveness. Explicitly out of scope here.

Goal for the whole initiative (confirmed with the user): usable on tablet and smaller screens. Not a full mobile-first redesign of every table — the priority is that the most-used chrome (menu, toolbar, forms) doesn't break, over making every dense table phone-perfect.

Problem (Phase 1 scope)

The sidebar built in the icon-rail feature (see 2026-07-07-sidebar-icon-rail-design.md) only toggles between full (260px) and rail (72px) width via a manual hamburger click — there's no automatic response to viewport size. On a tablet-width screen, a user has to remember to collapse it themselves; the shell doesn't adapt on its own.

Design

Behavior

Below 1024px viewport width, the sidebar automatically switches to rail mode (72px), reusing the exact isRailMode state + sidebar_rail_mode localStorage key already built for the manual toggle — no new state, no new CSS classes.
The user can still manually re-expand to full width via the existing hamburger button at any point, including while the viewport is below 1024px. That manual choice is not immediately re-collapsed — the automatic behavior only fires again on an actual re-crossing of the 1024px boundary (shrinking past it again), not continuously while already narrow.
Widening back above 1024px does not auto-expand the sidebar back to full — only auto-collapse on shrinking is automatic; expanding is always a manual, explicit action. This avoids undoing a user's deliberate manual collapse made while at desktop width.
On initial page load, if the viewport is already narrower than 1024px, the sidebar starts in rail mode regardless of what was last stored in localStorage for that browser profile (e.g. a first-time tablet user gets the right starting state; a desktop user who previously stored false and then narrows their window gets correctly collapsed too).

Mechanism

Angular CDK's BreakpointObserver (@angular/cdk/layout) watches (max-width: 1024px). This emits once immediately on subscribe with the current match state, then again only when the match state changes (not on every resize tick) — which is exactly the "fires on crossing, not continuously" behavior described above, with no manual debouncing needed.
MainLayoutComponent (which already owns isRailMode and its localStorage persistence from the icon-rail feature) subscribes to this observable in ngOnInit. Whenever it emits matches: true, isRailMode is set to true and persisted — mirroring exactly what onToggleRailMode(true) already does. Whenever it emits matches: false, nothing happens (no forced expand).
The subscription is torn down in ngOnDestroy (a new lifecycle hook on MainLayoutComponent, which doesn't implement OnDestroy today).
LayoutModule (@angular/cdk/layout) is registered in app.module.ts, the same way OverlayModule was added for the sidebar flyout.

What was checked and needs no change

tool-bar.component.scss's .user-display-name already has max-width: 200px; overflow: hidden; text-overflow: ellipsis — a long display name already truncates gracefully rather than overflowing the toolbar at narrower widths.
main-layout.component.html's content wrapper has no hardcoded min-width, so it doesn't itself force horizontal overflow at 1024px and below.

Out of scope

Any per-page table or form responsiveness (separate future phase/spec).
Any breakpoint other than the single 1024px tablet threshold.
Touch-specific interactions (this reuses the existing rail/flyout mouse-hover-and-click behavior as-is).

Testing

No automated test coverage exists for the layout shell (consistent with the icon-rail feature that preceded this). Verification is manual: resize the browser (or use devtools device emulation) across the 1024px boundary and confirm the sidebar collapses/expands as described, confirm a fresh load at a narrow width starts collapsed, and confirm manually re-expanding while narrow sticks until the boundary is crossed again.

4.8 KiB Raw Blame History