; ``` `Tooltip.Content` also now accepts `noArrow` for popover-like timeline labels and custom overlays. ### Patch Changes * ca1c8c7: Raise the `@tailor-platform/auth-public-client` dependency floor from `^0.5.0` to `^0.5.1` so fresh installs cannot resolve the broken `0.5.0` release. * 6e61cc2: Fix `DateField` / `DatePicker` not validating typed input against `minValue`, `maxValue`, or `isDateUnavailable`. A date entered by typing (or via a keyboard shortcut) that fell outside the allowed range was silently accepted. It's now flagged invalid (`aria-invalid` + a built-in message) while the value still flows through `onChange` — matching how the calendar already behaves and the react-aria validation contract. * Keyboard shortcuts (`t`, `m`, `y`, …) no longer clamp their target to the boundary; like typing, an out-of-range result is surfaced as invalid instead of being silently coerced. * `isDateUnavailable` now also drives field validation (e.g. weekends or specific blackout dates typed into the field are flagged), not just calendar selection. * Consumer `errorMessage` still takes precedence over the built-in messages. ## 1.8.0 ### Minor Changes * a4f735c: Add DateField, DatePicker, and Calendar components (@internationalized/date + Base UI implementation) Introduces three accessible date-input components, implemented on `@internationalized/date` (value layer) and Base UI (`Popover`) with hand-rolled segmented-input and calendar-grid behaviour: * `DateField` — segmented date/time input with label, description, and error message * `DatePicker` — date field with a popover calendar * `Calendar` — standalone calendar grid All three accept `LocalizedString` labels/descriptions and resolve locale + timezone from the AppShell context. The `@internationalized/date` value types (`CalendarDate`, `CalendarDateTime`, `ZonedDateTime`, …) and helpers (`parseDate`, `getLocalTimeZone`, …) are re-exported from `@tailor-platform/app-shell`. New AppShell context hooks: * `useResolvedLocale()` — full BCP-47 locale (e.g. `"en-GB"`) plus the language code * `useTimeZone()` — returns a `TimeZone` object with `.value` (IANA string), `.today()`, and `.now()` bound to the configured timezone AppShell now accepts an optional `timeZone` prop. > This is the **`@internationalized/date` + Base UI** variant — the lighter foundation tracked in the design proposal (§9). Net-new dependency is just `@internationalized/date` (~11 KB gz); Base UI is already in the bundle. Public API and accessibility contract are identical to the react-aria variant. > > **Known limitation:** the segmented input is built from `role="spinbutton"` elements that aren't `contentEditable`, so on-screen-keyboard typing on touch devices is limited — the calendar popover is the touch-friendly path (desktop keyboard entry works fully). The APG behaviour is unit-tested but not yet screen-reader-audited. * ef5c788: DataTable now scrolls internally: add `fill` prop to `Layout` to pin page chrome and scroll only the table rows. ```tsx … ``` With `fill`, the page title, table toolbar, column header row (sticky), and footer stay visible at all heights — only the rows region scrolls vertically. Without `fill`, pages grow and scroll as before. Tables short enough to fit render without a scrollbar or layout shift. **Behavior change:** the AppShell layout is now viewport-bounded (`h-svh` instead of `min-h-svh`), so page content scrolls inside the content area rather than on the document. Code relying on `window`/document scroll position should target the content area instead. Also fixes the empty/error state reserving `pageSize`-worth of height — it is now capped at 5 rows, so large page sizes no longer produce a huge blank region below "No data". * ef5c788: Add `useAppShellScrollContainer()` — a supported handle to the content scroll container Now that the shell is viewport-bounded (`h-svh`) and page content scrolls inside the content area rather than on the document, consumers that previously relied on `window`/document scroll need a stable way to reach the element that actually scrolls. `useAppShellScrollContainer()` returns a ref to that element: ```tsx const scrollRef = useAppShellScrollContainer(); useEffect(() => { const el = scrollRef.current; if (!el) return; const onScroll = () => setProgress(el.scrollTop / (el.scrollHeight - el.clientHeight)); el.addEventListener("scroll", onScroll, { passive: true }); return () => el.removeEventListener("scroll", onScroll); }, [scrollRef]); ``` Use it wherever you would previously have reached for `window.scrollY`, a `window` `scroll` listener, `window.scrollTo(...)`, or an `IntersectionObserver` with the default viewport root. * On a `` page the element does not scroll (its children manage their own scrolling). * Outside a `SidebarLayout` the ref's `current` is always `null`. * The container also carries a `data-appshell-scroll-container` attribute for non-React access (CSS, tests, `document.querySelector`). * aa9306a: Add a `header` slot to `SidebarLayout` and a `SidebarLayout.DefaultHeader` building block `SidebarLayout` now accepts a full-region `header?: ReactNode` prop, mirroring the existing `sidebar` slot. It defaults to the built-in header (`SidebarLayout.DefaultHeader`), so existing usage is unchanged. To extend the built-in header (e.g. add a notification bell or user menu) without reconstructing the trigger and breadcrumb, use `SidebarLayout.DefaultHeader` with its `actions` slot: ```tsx , , ]} /> } /> ``` * `DefaultHeader`'s `actions` prop (single node or array) controls the entire right-hand cluster, laid out in a horizontal, vertically-centered row. * `actions` **defaults to `[]`**, and **passing `actions` replaces the whole cluster including the switcher** — include `` explicitly to keep it. This keeps the API a single slot instead of accumulating one-off props. * `DefaultHeader` is available as `SidebarLayout.DefaultHeader` and as a top-level `DefaultHeader` export. * `DefaultSidebar` is now also exposed as `SidebarLayout.DefaultSidebar` for symmetry; the top-level `DefaultSidebar` export is retained for backwards compatibility. This provides an official, composable extension point for the top bar, replacing fragile consumer workarounds that queried the header DOM and injected a React portal. * 078130e: Add a `size` prop to `Tabs` and make `capsule` icon-only tabs square `Tabs.Root` now accepts `size?: "xs" | "sm" | "default" | "lg"` (default `"default"`), mirroring `Button`'s height tiers. It sets a **minimum** height on the `capsule` variant — taller content still grows — so a capsule track sits flush next to a `Button`: | `size` | capsule track | matches Button | | --------- | ------------- | -------------- | | `xs` | 28px | `size="xs"` | | `sm` | 32px | `size="sm"` | | `default` | 36px | default | | `lg` | 40px | `size="lg"` | Two `capsule` fixes from the same change: * The list no longer hard-locks to `h-10` (40px); its height derives from the tab size floor. * A tab whose only child is an icon now renders **square** (`min-width` follows `min-height`), instead of the previous wider-than-tall, shrunken look — ideal for icon-only view toggles. The default `capsule` height moves from 40px to 36px to align with `Button`'s default height. `size` only affects the `capsule` variant; `line` and `default` are unchanged. ### Patch Changes * eeb10ab: Remove the `stream` option from `useAIChat()` and `AIGatewayChatRequest`. AppShell now selects the appropriate transport (streaming vs JSON) automatically based on the model. Passing `stream` is no longer needed. ## 1.7.0 ### Minor Changes * 7f33506: Allow the standalone `Select`, `Combobox`, and `Autocomplete` (including their `.Async` variants) to receive an accessible name via `aria-label`, `aria-labelledby`, and `id`. Previously these props were silently dropped, leaving the combobox with only its current value as an accessible name — a WCAG 4.1.2 issue for filters and toolbars used outside a `Form`. The props are now forwarded to the underlying trigger/input. ```tsx // Announced as "Direction filter, combobox" instead of just its value ` that shares its base styles with the `Input` component. It can be omitted when using another AppShell input component (e.g. Select, Combobox, Autocomplete) as a sibling — those components register themselves with the Field context automatically. It also supports native HTML constraint attributes (`required`, `type="email"`, `pattern`, etc.) for built-in validation. ```tsx Email We'll never share your email. Please enter a valid email. ``` #### Using another AppShell component as the control `Field.Control` can be omitted when using a Base UI-backed AppShell component (e.g. Select, Combobox). The component registers itself with the Field context automatically, inheriting label association and validation state. ```tsx Country Please select a country. ``` #### Custom rendering with `Field.Validity` `Field.Validity` exposes the field's `ValidityState` via a render callback, allowing fully custom validation UI. ```tsx Password {(state) => (

{state.validity.valueMissing ? "❌" : "✅"} Required
{state.validity.tooShort ? "❌" : "✅"} At least 8 characters

)} ``` ### React Hook Form + Zod integration `Field.Root` accepts `isTouched`, `isDirty`, `invalid`, and `error` props that align with RHF's `fieldState` shape, so you can spread `fieldState` directly. Use `Form`'s `onSubmit` prop to connect RHF's `handleSubmit`. ```tsx import { useForm, Controller } from "react-hook-form"; import { zodResolver } from "@hookform/resolvers/zod"; import { z } from "zod"; const schema = z.object({ email: z.string().email() }); function MyForm() { const { control, handleSubmit } = useForm({ resolver: zodResolver(schema), }); return (

save(data))}> ( Email {fieldState.error?.message} )} /> ); } ``` The Field context co-exists with RHF — it only drives accessibility wiring (`htmlFor`, `aria-describedby`) and visual state (`data-invalid`, `data-dirty`, `data-touched`) without interfering with RHF's value management or validation lifecycle. * 524d49a: Add `MetricCard` component for dashboard KPI summaries (title, value, optional trend and description). ```tsx import { MetricCard } from "@tailor-platform/app-shell"; ; ``` * 135d5a9: Render module-level breadcrumb segments as non-clickable text when the module has no component. Modules defined without a `component` (group-only modules) now display their breadcrumb as plain text instead of a link, preventing navigation to non-existent pages. ### Patch Changes * 6dec130: Add `color-scheme: dark` to the `.dark` selector in theme CSS so that native form controls (e.g. ` console.log(value)} /> ``` ### Combobox Searchable combobox with single/multi selection. Pass `items` and get a fully assembled combobox with built-in filtering. Supports async data fetching via `Combobox.Async` and user-created items via `onCreateItem` prop. ```tsx console.log(value)} /> ``` ### Autocomplete Text input with a suggestion list. The value is the raw input string, not a discrete item selection. Also supports async suggestions via `Autocomplete.Async`. ```tsx console.log(value)} /> ``` ### Low-level primitives via `.Parts` `Select`, `Combobox`, and `Autocomplete` each expose a `.Parts` namespace containing the styled low-level sub-components (e.g. `Root`, `Input`, `Content`, `Item`, `List`, etc.) and hooks (`useFilter`, `useAsync`, `useCreatable`) for building fully custom compositions when the ready-made component doesn't fit your needs. ```tsx const { Root, Trigger, Content, Item } = Select.Parts; ``` ### Patch Changes * 8e11a5e: Updated lucide-react (^0.562.0 -> ^0.577.0) ## 0.30.0 ### Minor Changes * a8c5dcf: Export primitive UI components (`Button`, `Input`, `Table`, `Dialog`, `Sheet`, `Tooltip`) and update `@base-ui/react` to v1.3.0. ## New components ```tsx import { Button, Input, Table, Dialog, Sheet, Tooltip, } from "@tailor-platform/app-shell"; ``` ### Button Styled button with variant (`default`, `outline`, `destructive`, etc.) and size options. ```tsx ``` ### Input Styled text input with consistent theming. ```tsx ``` ### Dialog Modal dialog with compound component API (`Dialog.Root`, `Dialog.Content`, etc.). ```tsx }>Open Confirm Are you sure? }> Cancel ``` ### Sheet Slide-in panel backed by Drawer with native swipe-to-dismiss gesture support. ```tsx }>Open Settings ``` ### Tooltip Hover/focus tooltip with configurable placement and delay via `Tooltip.Provider`. ```tsx }>Hover me Help text ``` ### Table Semantic HTML table with pre-styled header, body, and footer sub-components. ```tsx Name Email Role Alice alice@example.com Admin ``` ## Other changes * `DescriptionCard`, `Layout`, and `Layout.Column` now accept an optional `style` prop for inline styles. * Fixed Dialog and Sheet overlay flashing on close animation. * Fixed missing `astw:` prefixes on sidebar utility classes that caused mobile sidebar UI bugs. ## 0.29.0 ### Minor Changes * fc59c8a: Add ActionPanel component for ERP-style action lists. **ActionPanel** — Card with a title and vertical list of actions (icon + label). Each row is a button triggered via `onClick`. The panel uses full width of its parent by default. ### Example ```tsx import { ActionPanel } from "@tailor-platform/app-shell"; , onClick: () => openCreateModal(), }, { key: "docs", label: "View documentation", icon: , onClick: () => window.open("/docs", "_blank", "noopener,noreferrer"), }, ]} />; ``` * 3e36ece: Allow modules and resources without a component for path-only definitions Modules and resources can now be defined without a `component`, both via `defineModule()`/`defineResource()` and file-based routing. This is useful when a directory exists solely to group child routes under a shared path prefix. Accessing a component-less path directly returns a 404 response, while child routes remain accessible as normal. ```tsx // Module without component — groups child resources under a shared path defineModule({ path: "admin", meta: { title: "Admin" }, resources: [ defineResource({ path: "users", component: () => }), defineResource({ path: "roles", component: () => }), ], }); // /admin → 404 // /admin/users → renders Users // /admin/roles → renders Roles // Resource without component — groups sub-resources under a namespace defineResource({ path: "namespace", subResources: [ defineResource({ path: "page-a", component: () =>

Page A

}), ], }); // /namespace → 404 // /namespace/page-a → renders Page A ``` For file-based routing, simply omit `page.tsx` from a directory: ``` pages/ admin/ users/ page.tsx ← /admin/users renders this roles/ page.tsx ← /admin/roles renders this (no page.tsx for /admin itself → 404) ``` Guards on component-less routes now execute correctly. Previously, guard loaders were silently ignored when no component was present. Now, guards such as `redirectTo()` will fire as expected, and if all guards return `pass()`, the route falls back to a 404. * 565ae70: Add `Layout.Header` sub-component and `area` prop to `Layout.Column`. ## Motivation The current `Layout` component requires a `columns` prop that must exactly match the number of `Layout.Column` children, and embeds header concerns (`title`, `actions`) directly into the layout component. This coupling creates several issues: * **Redundant declaration** — The column count can be inferred from the number of `Layout.Column` children, making the `columns` prop unnecessary boilerplate. * **Limited column placement** — The 2-column template always treats the 1st column as main (flex) and the 2nd as a fixed sidebar. There is no way to express a "left sidebar + main content" layout. * **Mixed responsibilities** — `Layout` handles both page heading (title/actions) and column arrangement. Separating these into `Layout.Header` and `Layout.Column` makes each concern independently composable — for example, placing tabs between the header and columns. ## What's New * **`Layout.Header`**: Compose inside `Layout` for title, actions, and extra content (e.g. tabs) above columns. * **`Layout.Column` `area` prop**: Declare column roles (`left`, `main`, `right`) for area-based width templates, enabling layouts like left sidebar + main that were previously not possible. * **`columns` and `gap` props are deprecated**: Column count is auto-detected from children; use `className` for gap. * **No runtime breaking changes** — existing code continues to work as-is. Note: `columns` is now optional, so code that directly reads `LayoutProps["columns"]` as a non-optional type will need adjustment. ## Usage ```tsx // With Layout.Header (title, actions, and extra content such as tabs) Save]}> ... {/* Renders below title/actions, above Columns */} Main content Side panel // With area prop (Left + Main) Side nav Main content // With area prop (3 columns) Left panel Main content Right panel // Existing API still works Save]} columns={2}> Main content Side panel ``` ## Sub-components | Component | Status | Props | | --------------- | -------- | --------------------------------------------------------------- | | `Layout.Column` | Retained | `area?: "left" \| "main" \| "right"`, `className?`, `children?` | | `Layout.Header` | **New** | `title?`, `actions?: ReactNode[]`, `children?: ReactNode` | ## Children Rules * **`Layout.Header`** — At most one. If multiple are provided, only the first is rendered. * **`Layout.Column`** — 1–3 columns use position-based or area-based width templates. 4+ columns use equal-width (`repeat(N, 1fr)`). * **`area` prop** — When any column specifies `area`, all columns switch to area-based widths. Columns without `area` default to `1fr`. * **Anything else** — Silently filtered out (not rendered). ## Width Templates ### Position-based (no `area`, unchanged from current API) | Column Count | Responsive Behavior | Width Distribution | | ------------ | ------------------------------------------ | -------------------------------------------- | | 1 | Always stacked vertically | Full width | | 2 | < 1024px: stacked / ≥ 1024px: side-by-side | 1st flex-1, 2nd fixed 280px | | 3 | < 1280px: stacked / ≥ 1280px: side-by-side | 1st fixed 320px, 2nd flex-1, 3rd fixed 280px | | 4+ | < 1280px: stacked / ≥ 1280px: side-by-side | All columns equal width (`repeat(N, 1fr)`) | ### Area-based (with `area` prop) | Area | Width | | ------- | ----------- | | `left` | Fixed 320px | | `main` | flex-1 | | `right` | Fixed 280px | Responsive behavior is the same: 2 columns break at 1024px, 3+ columns break at 1280px. ## 0.28.0 ### Minor Changes * 4cb5295: Replaced `getAuthHeadersForQuery` with `auth-public-client` 0.5.0's built-in `fetch()` method. **Breaking change:** `EnhancedAuthClient.getAuthHeadersForQuery()` has been removed. Use `authClient.fetch` instead, which transparently handles DPoP proof generation and token refresh. **Migration:** ```diff const urqlClient = createClient({ url: `${authClient.getAppUri()}/query`, - fetchOptions: async () => { - const headers = await authClient.getAuthHeadersForQuery(); - return { headers }; - }, + fetch: authClient.fetch, }); ``` ## 0.27.3 ### Patch Changes * 10cb588: Remove horizontal padding in Layout component * 24f8eb1: Updated es-toolkit (^1.44.0 -> ^1.45.1) ## 0.27.2 ### Patch Changes * b01718f: Updated graphql (^16.12.0 -> ^16.13.0) * ed5f14f: Fixed incorrect `types` path in `package.json` exports. The `"."` entry was pointing to `./dist/index.d.ts` which does not exist. Updated to `./dist/app-shell.d.ts` to match the actual build output. * d0dc61b: Reorganized README and documentation structure for public-facing clarity. Added `docs/quickstart.md`, created NPM-facing `packages/core/README.md` with motivation and feature highlights, and ensured each documentation layer (root README, package READMEs, docs/) serves a distinct purpose. ## 0.27.1 ### Patch Changes * e1a12c8: Migrated internal UI primitives from Radix UI/shadcn to Base UI. **Updated dependencies:** * Removed: `@radix-ui/react-checkbox`, `@radix-ui/react-collapsible`, `@radix-ui/react-dialog`, `@radix-ui/react-dropdown-menu`, `@radix-ui/react-label`, `@radix-ui/react-navigation-menu`, `@radix-ui/react-popover`, `@radix-ui/react-separator`, `@radix-ui/react-slot`, `@radix-ui/react-tooltip` * Added: `@base-ui/react` (^1.2.0) This is an internal refactoring with no changes to the public API. ## 0.27.0 ### Minor Changes * a7f686f: Adds new Sidebar custom items API for flexible sidebar navigation customization. ## New Components * `SidebarItem` - Navigation item that auto-resolves title/icon from resource meta * `SidebarGroup` - Collapsible group for organizing navigation items * `SidebarSeparator` - Visual separator between sidebar sections * `WithGuard` - Conditional rendering wrapper based on guard functions ## New Hook * `usePageMeta` - Hook to access current page metadata (title, icon) ## Usage ```tsx import { SidebarLayout, DefaultSidebar, SidebarItem, SidebarGroup, SidebarSeparator, } from "@tailor-platform/app-shell"; // Auto-resolved navigation from resource definitions (DefaultSidebar is used by default) // Fully customized sidebar navigation }> } /> // Custom rendering with render prop (

{icon} {title}

)} /> ``` ## WithGuard Component New `WithGuard` component for conditional rendering based on guard functions. Use it to control visibility of sidebar items or any other components. ```tsx import { WithGuard, pass, hidden } from "@tailor-platform/app-shell"; // Define a guard function const isAdminGuard = ({ context }) => context.currentUser.role === "admin" ? pass() : hidden(); // Wrap components with WithGuard }> ; // Curried guards for parameterized conditions const hasRole = (role: string) => ({ context }) => context.currentUser.role === role ? pass() : hidden(); ; // Use in page components for conditional UI const DashboardPage = () => (

Dashboard

); ``` * e7fa8ec: Add file-based routing support via new Vite plugin File-based routing allows defining pages by placing components in a directory structure, eliminating the need for explicit `defineModule()` and `defineResource()` calls. ### Why file-based routing? **URL-First Design is Already the Norm** - Most projects naturally align their module/resource hierarchy with URL paths. A "purchasing" module at `/purchasing` with an "orders" resource at `/purchasing/orders` is the intuitive choice. The previous API required manually wiring up this structure even though the mapping was already implicit. **AI-Friendly Development** - By adopting file-based routing patterns pioneered by Next.js, AI tools can understand and navigate your codebase with less context. Code generation becomes more predictable and the established convention serves as shared knowledge between humans and AI. **Providing Rails, Not Just Flexibility** - The legacy `defineModule()`/`defineResource()` API gave flexibility but offered few conventions for directory structure, hierarchy management, or file naming. File-based routing provides an opinionated, battle-tested convention. Importantly, this is implemented as a Vite plugin layer on top of the existing programmatic API. Projects requiring non-standard routing can still use `defineModule()`/`defineResource()` directly. ### Backward Compatibility File-based routing is a **recommended opt-in** feature. The legacy declarative API (`defineModule()`/`defineResource()`) remains fully supported and will continue to work. You can choose either approach per project, though mixing both in the same application is not supported. ### Vite Plugin The new `@tailor-platform/app-shell-vite-plugin` package provides file-based routing support: ```typescript // vite.config.ts import { appShellRoutes } from "@tailor-platform/app-shell-vite-plugin"; export default defineConfig({ plugins: [ react(), appShellRoutes(), // scans src/pages by default ], }); ``` Under the hood, the plugin: 1. **Scans pages** - Finds `page.tsx` files in `src/pages` and builds a route tree 2. **Generates virtual module** - Creates `virtual:app-shell-pages` with all discovered pages 3. **Auto-injects pages** - Intercepts `@tailor-platform/app-shell` imports and wraps `AppShell` with `AppShell.WithPages(pages)` 4. **Validates at build time** - Uses ts-morph AST analysis to validate `appShellPageProps` 5. **Supports HMR** - Watches for page changes and triggers hot reload No manual wiring needed—just import `AppShell` as usual and pages are automatically available. ### Defining Pages ```tsx // src/pages/dashboard/page.tsx import type { AppShellPageProps } from "@tailor-platform/app-shell"; const DashboardPage = () =>

Dashboard

; DashboardPage.appShellPageProps = { meta: { title: "Dashboard" }, guards: [authGuard], } satisfies AppShellPageProps; export default DashboardPage; ``` ### Type-safe Routes (Optional) ```typescript // vite.config.ts appShellRoutes({ generateTypedRoutes: true }); ``` When enabled, the plugin generates `src/routes.generated.ts` containing: * `GeneratedRouteParams` type mapping all routes to their parameter types * `paths` helper with a type-safe `for()` method for building URLs * Module augmentation to register route types with app-shell ```tsx // Auto-generated: src/routes.generated.ts export type GeneratedRouteParams = { "/": {}; "/dashboard": {}; "/dashboard/orders/:id": { id: string }; }; export const paths = createTypedPaths(); // Usage - TypeScript enforces correct params import { paths } from "./routes.generated"; paths.for("/dashboard"); // ✓ OK paths.for("/dashboard/orders/:id", { id: "123" }); // ✓ OK → "/dashboard/orders/123" paths.for("/dashboard/orders/:id"); // ✗ Error: missing 'id' paths.for("/invalid-route"); // ✗ Error: route doesn't exist ``` ### Breaking Change: Guard/Loader Cascade Behavior In the legacy `defineModule()`/`defineResource()` API, guards and loaders defined at the module level were automatically cascaded to all child resources. This automatic cascade behavior has been removed in both the legacy API and file-based routing—**guards and loaders are no longer automatically inherited**. Each resource or page must explicitly define its own guards and loaders. **Before (legacy API):** ```tsx defineModule({ path: "/dashboard", guards: [authGuard], // Applied to all child resources automatically resources: [ defineResource({ path: "/orders", element: }), // authGuard applied defineResource({ path: "/reports", element: }), // authGuard applied ], }); ``` **After (legacy API):** ```tsx defineModule({ path: "/dashboard", guards: [authGuard], resources: [ defineResource({ path: "/orders", guards: [authGuard], element: , }), // Must be explicitly defined defineResource({ path: "/reports", guards: [authGuard], element: , }), // Must be explicitly defined ], }); ``` Note: File-based routing, introduced in this release, also does not support guard/loader cascading. Each page must define its own guards and loaders explicitly: ```tsx // src/pages/dashboard/orders/page.tsx OrdersPage.appShellPageProps = { guards: [authGuard], // Must be explicitly defined } satisfies AppShellPageProps; // src/pages/dashboard/reports/page.tsx ReportsPage.appShellPageProps = { guards: [authGuard], // Must be explicitly defined } satisfies AppShellPageProps; ``` **Rationale:** Explicit guard/loader definitions per resource/page improve code clarity and make it easier to understand the security requirements of each route at a glance. **Migration tip:** If you need the previous cascading behavior, compose your guards array explicitly: ```tsx // src/guards.ts export const requireAuth = [authGuard]; export const requireAdmin = [authGuard, adminRoleGuard]; // src/pages/dashboard/orders/page.tsx import { requireAuth } from "@/guards"; OrdersPage.appShellPageProps = { guards: [...requireAuth, canViewOrders], } satisfies AppShellPageProps; // src/pages/admin/users/page.tsx import { requireAdmin } from "@/guards"; UsersPage.appShellPageProps = { guards: [...requireAdmin], } satisfies AppShellPageProps; ``` ## Breaking Change: Module without component requires guards As part of the ongoing effort to decouple navigation and routing (aligned with file-based routing), the automatic redirect behavior for modules without a `component` has been removed. Previously, a module without a `component` would automatically redirect to the first visible resource. However, in file-based routing, the resource hierarchy is determined ad-hoc by the vite-plugin based on directory structure, making this implicit redirect behavior inconsistent and unpredictable. To maintain consistency across both explicit and file-based routing, this behavior has been removed. If a module is defined without both `component` and `guards`, an error will be thrown at runtime. You must provide at least one of them. ```tsx // Before: automatic redirect to first visible resource defineModule({ path: "reports", resources: [salesResource, usersResource], }); // After: explicit redirect via guards defineModule({ path: "reports", guards: [() => redirectTo("sales")], resources: [salesResource, usersResource], }); // Error: defining a module without both component and guards will throw defineModule({ path: "reports", resources: [salesResource, usersResource], }); // => throws an error ``` ### Patch Changes * 8c19779: Updated react-hook-form (^7.71.1 -> ^7.71.2) * 50ddd5f: Updated tailwind-merge (^3.4.0 -> ^3.5.0) * 1338776: Updated es-toolkit (^1.41.0 -> ^1.44.0) * Updated dependencies \[e7fa8ec] * @tailor-platform/app-shell-vite-plugin@0.27.0 ## 0.26.3 ### Patch Changes * 2170b9e: Updated oauth4webapi (^3.8.3 -> ^3.8.5) * 5aef4ad: Update auth-public-client to 0.4.1 * 18f9b66: Updated react-hook-form (^7.54.2 -> ^7.71.1) ## 0.26.2 ### Patch Changes * 7fee07a: Updated @tanstack/react-table (^8.21.2 -> ^8.21.3) ## 0.26.1 ### Patch Changes * 3fe975b: Fix content area layout to properly fill remaining space Added `flex-1` and `min-h-0` to the content wrapper in SidebarLayout, allowing child pages to use `h-full` or `flex-1` to fill the remaining space after the header/breadcrumb. This eliminates the need for hacky `calc(100dvh - Xrem)` workarounds. Also added `overflow-hidden` to the sidebar-wrapper to enable proper scrolling within nested containers (e.g., kanban board lanes). ## 0.26.0 ### Minor Changes * 72bbcb6: Replace `@tailor-platform/auth-browser-client` with `@tailor-platform/auth-public-client` and add Suspense support ## Motivation The previous authentication implementation using `@tailor-platform/auth-browser-client` relied on HTTPOnly cookie-based session management. This caused authentication failures on browsers with strict privacy protections, particularly Safari with its Intelligent Tracking Prevention (ITP) feature, and Brave with its similar tracking prevention mechanisms. These browsers block or restrict cross-site cookies, which prevented the HTTPOnly cookies from being stored and sent properly, causing authentication to fail silently or users to be logged out unexpectedly. To address this cross-browser compatibility issue, we have migrated to `@tailor-platform/auth-public-client`, which uses DPoP (Demonstrating Proof of Possession) token binding with IndexedDB storage instead of cookies. This approach works reliably across all major browsers (including Safari 14+ and Brave) regardless of their privacy settings. ## Key Changes * **Cross-browser Compatibility**: Works reliably on Safari, Brave, and other browsers with strict privacy settings * **Suspense Support**: Added `useAuthSuspense` hook for React Suspense integration * **Module-level Client**: Auth client can now be created at module level and shared across the app ## Breaking Changes The underlying authentication package has been replaced with `@tailor-platform/auth-public-client` v0.3.1, which uses DPoP (Demonstrating Proof of Possession) token binding. ### AuthProvider API Changes * `AuthProvider` now requires a `client` prop created with `createAuthClient` from `@tailor-platform/app-shell` * The `apiEndpoint` prop has been removed - the client automatically uses the `appUri` provided during creation * You must use the wrapped `createAuthClient` from `@tailor-platform/app-shell` (not the original from `@tailor-platform/auth-public-client`) ### Hook Return Value Changes * **`useAuth`**: Now returns `{ isAuthenticated, error, isReady, login, logout, checkAuthStatus }` directly instead of `{ authState, ... }` * **`useAuthSuspense`**: Returns `{ isAuthenticated, error, login, logout, checkAuthStatus }` (no `isReady` since Suspense handles loading) ### Removed Exports * `DefaultUser` and `AuthRegister` types are no longer exported * `user` property removed from `AuthState` (see "Removed: Built-in User Fetching" below) ### Removed: Built-in User Fetching (meQuery) The previous implementation fetched user information internally using a simple `fetch` call to the `/query` endpoint. This design had several issues: 1. **Caching conflicts**: When applications use GraphQL client libraries (urql, Apollo, etc.) with sophisticated caching mechanisms, having a separate internal fetch for user data creates inconsistencies and bypasses the cache. 2. **Inflexibility**: Applications couldn't customize the user query or integrate it with their existing data fetching patterns. 3. **Mixed responsibilities**: The auth provider was handling both authentication AND user data fetching, which are separate concerns. **The new design focuses solely on authentication responsibilities:** * Token management (access tokens, refresh tokens) * Login/logout flows * OAuth callback handling * Authentication state (`isAuthenticated`, `error`, `isReady`) **User information should now be fetched by your application** using your preferred GraphQL client library, which gives you: * Full control over caching behavior * Ability to customize the user query * Consistent data fetching patterns across your app * Better integration with your existing data layer ## Migration Guide ### Before (v0.22.0 and earlier) ```tsx import { AuthProvider, useAuth } from "@tailor-platform/app-shell"; function App() { return ( ); } function MyComponent() { const { authState, login, logout } = useAuth(); if (authState.isLoading) return

; if (!authState.isAuthenticated) return ; // User was available from authState return

Welcome, {authState.user?.email}!

; } ``` ### After (v0.23.0+) ```tsx import { createAuthClient, AuthProvider, useAuth, } from "@tailor-platform/app-shell"; // Create auth client outside component (module level) const authClient = createAuthClient({ clientId: "your-client-id", appUri: "https://xyz.erp.dev", redirectUri: "https://your-app.com", // optional, defaults to window.location.origin }); function App() { return ( ); } function MyComponent() { // New: properties returned directly (not nested in authState) const { isAuthenticated, isReady, login, logout } = useAuth(); if (!isReady) return

; if (!isAuthenticated) return ; // User info should now be fetched separately using your GraphQL client return ; } // Fetch user info with your GraphQL client (e.g., urql) function UserProfile() { const [{ data }] = useQuery({ query: ME_QUERY }); return

Welcome, {data?.me?.email}!

; } ``` ## Usage Examples ### Basic Authentication ```tsx import { createAuthClient, AuthProvider, useAuth, } from "@tailor-platform/app-shell"; const authClient = createAuthClient({ clientId: "your-client-id", appUri: "https://xyz.erp.dev", }); function App() { return ( ); } function MyComponent() { const { isAuthenticated, isReady, login, logout } = useAuth(); if (!isReady) return

; if (!isAuthenticated) return ; return (

Authenticated!

); } ``` ### With Suspense ```tsx import { Suspense } from "react"; import { createAuthClient, AuthProvider, useAuthSuspense, } from "@tailor-platform/app-shell"; const authClient = createAuthClient({ clientId: "your-client-id", appUri: "https://xyz.erp.dev", }); function App() { return ( Loading authentication...

Dashboard

{pageProps.title}