@rebasepro/ui 0.14.1 → 0.14.2-canary.g27a129e

package/src/styles.ts

@@ -53,7 +53,53 @@ export const fieldBackgroundInvisibleMixin = "bg-surface-accent-200/0 dark:bg-wh
 export const fieldBackgroundDisabledMixin = "bg-surface-accent-200/50 dark:bg-white/[0.03]";
 export const fieldBackgroundHoverMixin = "hover:bg-surface-accent-200/70 hover:dark:bg-white/[0.09]";
 export const defaultBorderMixin = "border-surface-200 dark:border-surface-700/60 ";
+
+// ---------------------------------------------------------------------------
+// Surfaces: two kinds, and the difference is what the border is for.
+//
+// A **floating** surface — a menu, a dialog, a popover — sits OVER the page. It
+// has to be legible against whatever happens to be underneath it, so its edge
+// is definite: solid `surface-700`. That is `paperMixin`.
+//
+// A **page** surface — a card in the document flow — sits ON the page, and the
+// page is already `surface-950`/`surface-900`. A solid edge there reads as a
+// box drawn around content rather than as the content having a surface, which
+// is why every serious caller was overriding it: 53 `<Card>` sites in the SaaS
+// console alone re-declared this border at `/60`, the same value
+// `defaultBorderMixin` above has always used. The component was wrong and the
+// callers were right, so the component now says what they meant.
+// ---------------------------------------------------------------------------
 export const paperMixin = "bg-white rounded-lg dark:bg-surface-900 border border-surface-200 dark:border-surface-700";
-export const cardMixin = "bg-white dark:bg-surface-900 rounded-lg border border-surface-200 dark:border-surface-700";
+export const cardMixin = "bg-white dark:bg-surface-900 rounded-xl border border-surface-200 dark:border-surface-700/60";
+
+/**
+ * An inset well: code, a query, a log tail, a connection string.
+ *
+ * It must read as *recessed into* the surface holding it, which means darker
+ * than that surface in dark mode — `surface-950` under a `surface-900` card.
+ * The obvious-looking `surface-800` is a trap: `#111111` is LIGHTER than the
+ * `#0a0a0a` card around it, so the well appears to float above the thing it is
+ * set into. Pair with `font-mono`; this mixin carries the surface only.
+ */
+export const codeSurfaceMixin = "bg-surface-100 dark:bg-surface-950 rounded-md";
+
+/**
+ * The accent, used as TEXT.
+ *
+ * `--color-primary` (#0070F4) is tuned to be a fill — white text on it, it on
+ * white. Read as text on our dark surfaces it lands at **4.36:1 on a
+ * `surface-900` card** (measured), which is below AA for body-sized text, and
+ * every accent link in the product sits on exactly that surface. On the page's
+ * `surface-950` it only reaches 4.62:1, so the margin was never real.
+ *
+ * `--color-primary-light` is the same hue lifted 0.15 in OKLCH lightness and
+ * measures **7.34:1** on the same card. It is indistinguishable as "the blue"
+ * and comfortably legible, so dark mode swaps to it for text.
+ *
+ * Use this for links, accent labels and any accent-coloured type. It is NOT for
+ * fills — a filled button keeps `bg-primary`, where the contrast question runs
+ * the other way and #0070F4 is already correct.
+ */
+export const accentTextMixin = "text-primary dark:text-primary-light";
 export const cardClickableMixin = "hover:bg-primary/5 dark:hover:bg-primary/5 cursor-pointer transition-colors duration-150";
 export const cardSelectedMixin = "bg-primary-bg/30 dark:bg-primary-bg/10 ring-1 ring-primary/75";

package/src/theme.css

@@ -30,11 +30,14 @@
     --tracking-title: -0.018em;   /* 20-24px — section titles */
     --tracking-heading: -0.01em;  /* <= 18px — labels; still a heading, not a headline */
 
-    /* Sub-`xs` type. MARKETING ONLY — product UI must not go below `text-xs`
-       (12px). These exist because the marketing site had ~450 hand-written
-       `text-[10px]` / `text-[11px]` classes: the tier was real, it just wasn't
-       in the system, so every page improvised it. Naming it stops the drift
-       without pretending 10px is acceptable for an admin panel. */
+    /* Sub-`xs` type. These exist because the marketing site had ~450
+       hand-written `text-[10px]` / `text-[11px]` classes: the tier was real, it
+       just wasn't in the system, so every page improvised it.
+
+       In product UI there is exactly ONE sanctioned use — `typography-micro`,
+       the uppercase field label above a value — and it earns the exception by
+       never carrying a sentence. Everything a person actually *reads* stays at
+       `text-xs` (12px) or above. `--text-3xs` remains marketing-only. */
     --text-2xs: 11px;
     --text-2xs--line-height: 1.45;
     --text-3xs: 10px;

package/src/util/chip_colors.ts

@@ -7,6 +7,98 @@ export type ChipColorScheme = {
     darkColor?: string;
     /** Text color override for dark mode */
     darkText?: string;
+    /**
+     * Ink for the `outlined` variant, which has no fill of its own.
+     *
+     * `text`/`darkText` are the ink ON the chip's own background. An outlined
+     * chip drops that background and sits on the PAGE, so the same value is
+     * being asked to be legible against two different surfaces at once — and
+     * for most hues it cannot be. Splitting the roles is what lets the filled
+     * ink follow its fill (often dark ink on a bright chip) without dragging
+     * the outlined variant down with it.
+     */
+    outlineText?: string;
+    /** Outlined-variant ink in dark mode. */
+    darkOutlineText?: string;
+}
+
+/* ────────────────────────────────────────────────────────────────────────────
+   Contrast
+   ────────────────────────────────────────────────────────────────────────────
+
+   Chip ink is DERIVED, not hand-picked. It used to be written down per tone —
+   `"#fff"` on every `solid` background, the hue's `pale` on every `deep` one —
+   and an audit of all 120 hue/tone/mode pairs found **63 of them below WCAG AA**.
+   The worst was white on `teal.solid` at **1.76:1**, which is not a near miss;
+   it is unreadable. The palette is an Airtable-style one whose mid stops are
+   bright enough to need dark ink, and hardcoding light ink ignored that.
+
+   So the ink is measured against the background it will actually sit on, and
+   pushed toward black or white only as far as it must go to clear the floor.
+   Starting from the hue's own dark/light tints rather than from flat `#000`
+   and `#fff` keeps the family looking like a family: `blue.solid` gets a very
+   dark navy, not black.
+
+   Deriving it also means a new hue cannot be added below AA — there is no
+   per-tone ink to forget to check. */
+
+/** WCAG floor, plus a little margin so rounding cannot drop a pair below 4.5. */
+const CONTRAST_TARGET = 4.6;
+
+/** Page backgrounds the outlined variant sits on: `bg-white` and `surface-950`. */
+const PAGE_LIGHT = "#ffffff";
+const PAGE_DARK = "#0a0a0a";
+
+function toRgb(hex: string): [number, number, number] {
+    let h = hex.replace("#", "");
+    if (h.length === 3) h = h.split("").map(c => c + c).join("");
+    return [0, 2, 4].map(i => parseInt(h.slice(i, i + 2), 16)) as [number, number, number];
+}
+
+function toHex(rgb: number[]): string {
+    return "#" + rgb.map(v => Math.round(Math.max(0, Math.min(255, v))).toString(16).padStart(2, "0")).join("");
+}
+
+function relativeLuminance(hex: string): number {
+    const [r, g, b] = toRgb(hex).map(v => {
+        const c = v / 255;
+        return c <= 0.03928 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4);
+    });
+    return 0.2126 * r + 0.7152 * g + 0.0722 * b;
+}
+
+export function contrastRatio(a: string, b: string): number {
+    const x = relativeLuminance(a);
+    const y = relativeLuminance(b);
+    const [hi, lo] = x > y ? [x, y] : [y, x];
+    return (hi + 0.05) / (lo + 0.05);
+}
+
+function mixHex(from: string, to: string, t: number): string {
+    const A = toRgb(from);
+    const B = toRgb(to);
+    return toHex([0, 1, 2].map(i => A[i] + (B[i] - A[i]) * t));
+}
+
+/**
+ * Walk a tinted ink toward black or white until it clears the floor on `bg`.
+ *
+ * Stops at the first passing step rather than going all the way, so the ink
+ * keeps as much of its hue as legibility allows.
+ */
+function push(base: string, toward: string, bg: string): string {
+    for (let t = 0; t <= 1.0001; t += 0.02) {
+        const candidate = mixHex(base, toward, t);
+        if (contrastRatio(candidate, bg) >= CONTRAST_TARGET) return candidate;
+    }
+    return toward;
+}
+
+/** The ink for a chip filled with `bg`: whichever direction has more headroom. */
+function inkOn(stops: HueStops, bg: string): string {
+    const dark = push(stops.text, "#000000", bg);
+    const light = push(stops.onDeep ?? stops.pale, "#ffffff", bg);
+    return contrastRatio(dark, bg) >= contrastRatio(light, bg) ? dark : light;
 }
 
 /**
@@ -61,18 +153,40 @@ const HUE_STOPS: Record<ChipHue, HueStops> = {
     emerald: { pale: "#d1fae5", mid: "#6ee7b7", solid: "#10b981", deep: "#059669", text: "#064e3b" }
 };
 
+/**
+ * One tone of one hue.
+ *
+ * Backgrounds are the palette's, unchanged — the stops were not the problem and
+ * moving them would have restyled every chip in the product. Only the ink moved,
+ * and it moved to wherever the measurement says it has to be.
+ */
 function tone(stops: HueStops, chipTone: ChipTone): ChipColorScheme {
-    const onDeep = stops.onDeep ?? stops.pale;
+    // The outlined variant is a property of the HUE, not of the tone: it has no
+    // fill, so every tone of a hue sits on the same page background and wants
+    // the same ink.
+    const outline = {
+        outlineText: push(stops.text, "#000000", PAGE_LIGHT),
+        darkOutlineText: push(stops.onDeep ?? stops.pale, "#ffffff", PAGE_DARK)
+    };
+
+    const filled = (light: string, dark: string): ChipColorScheme => ({
+        color: light,
+        text: inkOn(stops, light),
+        darkColor: dark,
+        darkText: inkOn(stops, dark),
+        ...outline
+    });
+
     switch (chipTone) {
         case "Light":
-            return { color: stops.mid, text: stops.text, darkColor: stops.solid, darkText: "#fff" };
+            return filled(stops.mid, stops.solid);
         case "Dark":
-            return { color: stops.solid, text: "#fff", darkColor: stops.solid, darkText: "#fff" };
+            return filled(stops.solid, stops.solid);
         case "Darker":
-            return { color: stops.deep, text: onDeep, darkColor: stops.deep, darkText: onDeep };
+            return filled(stops.deep, stops.deep);
         case "Lighter":
         default:
-            return { color: stops.pale, text: stops.text, darkColor: stops.deep, darkText: onDeep };
+            return filled(stops.pale, stops.deep);
     }
 }
 

package/src/util/lazy_chunk.ts

@@ -0,0 +1,101 @@
+import React from "react";
+
+/**
+ * Dynamic imports that survive a redeploy.
+ *
+ * A built SPA names its chunks by content hash and a deploy replaces the whole
+ * `assets/` directory, so a tab opened before the deploy still holds the *old*
+ * entry chunk. The first lazy route that tab opens asks for a hash that no
+ * longer exists on the server, the import rejects, and the view is dead until
+ * the user thinks to reload — which nothing on screen tells them to do. The
+ * browser's own wording ("Failed to fetch dynamically imported module: …") reads
+ * like a build bug, so this is usually reported as one.
+ *
+ * `loadChunk` retries once — that covers a transient network failure — and then
+ * gives up with an error tagged as a chunk load failure, so `ErrorBoundary` can
+ * offer a reload instead of printing the browser's message.
+ */
+
+/**
+ * Marker property set on the error thrown after a failed retry. Read by
+ * `isChunkLoadError`, which is what the UI matches on.
+ */
+const CHUNK_LOAD_ERROR_FLAG = "rebaseChunkLoadError";
+
+/**
+ * Each engine words this differently, and the message is the only signal — none
+ * of them use a distinguishable error type. The MIME variants matter as much as
+ * the fetch ones: a server whose SPA fallback answers a missing `/assets/x.js`
+ * with `index.html` returns 200 HTML, and the browser rejects it as a module.
+ */
+const CHUNK_ERROR_PATTERNS = [
+    "failed to fetch dynamically imported module",
+    "error loading dynamically imported module",
+    "importing a module script failed",
+    "failed to load module script",
+    "expected a javascript",
+    "unable to preload css"
+];
+
+/**
+ * Does this error mean a chunk could not be loaded — rather than the chunk's
+ * own code throwing once it did load?
+ *
+ * Errors raised anywhere are matched, not just ones `loadChunk` produced: React
+ * `lazy()` calls that still import directly, and Vite's own CSS preloads, fail
+ * the same way and deserve the same recovery.
+ */
+export function isChunkLoadError(error: unknown): boolean {
+    if (!error || typeof error !== "object") return false;
+    if ((error as Record<string, unknown>)[CHUNK_LOAD_ERROR_FLAG] === true) return true;
+    const message = (error as { message?: unknown }).message;
+    if (typeof message !== "string") return false;
+    const lower = message.toLowerCase();
+    return CHUNK_ERROR_PATTERNS.some(pattern => lower.includes(pattern));
+}
+
+function chunkLoadError(cause: unknown): Error {
+    const error = new Error(
+        "This app was updated while the tab was open, so part of it could not be loaded. Reload to continue."
+    );
+    Object.assign(error, { [CHUNK_LOAD_ERROR_FLAG]: true,
+cause });
+    return error;
+}
+
+/**
+ * Run a dynamic import, retrying once before declaring the chunk unreachable.
+ *
+ * Errors that are not chunk load failures — the imported module throwing while
+ * it evaluates, say — are re-thrown untouched and never retried: running a
+ * module's side effects twice is worse than the original failure.
+ */
+export async function loadChunk<T>(loader: () => Promise<T>): Promise<T> {
+    try {
+        return await loader();
+    } catch (error) {
+        if (!isChunkLoadError(error)) throw error;
+        // A blip resolves inside a few hundred ms; a stale hash never will.
+        await new Promise(resolve => setTimeout(resolve, 250));
+        try {
+            return await loader();
+        } catch (retryError) {
+            throw chunkLoadError(retryError);
+        }
+    }
+}
+
+/**
+ * `React.lazy` with the retry above. A drop-in replacement — use it for every
+ * lazy route or dialog, since any one of them can be the first chunk a stale
+ * tab reaches for.
+ *
+ * Note that React caches the rejection: once a lazy component has failed, later
+ * renders re-throw without calling the loader again. Resetting an error boundary
+ * therefore cannot recover it, which is why the boundary offers a reload.
+ */
+export function lazyChunk<T extends React.ComponentType<any>>(
+    loader: () => Promise<{ default: T }>
+): React.LazyExoticComponent<T> {
+    return React.lazy(() => loadChunk(loader));
+}

package/src/views/CollectionView/CollectionView.tsx

@@ -12,6 +12,7 @@ import type {
     CollectionPropertyConfig,
     CollectionDataController,
     CellRendererOverride,
+    CollectionCustomViewEntry,
     CollectionSelectionController,
     KanbanPropertyOption
 } from "./CollectionViewTypes";
@@ -134,6 +135,27 @@ export interface CollectionViewProps<T = Record<string, unknown>> {
     /** Custom empty state component */
     emptyComponent?: React.ReactNode;
 
+    /**
+     * Additional ways to render these rows, keyed by view mode. A key here can
+     * be named by `viewMode`, `defaultViewMode` and `enabledViews`, and gets
+     * its own entry in the view switcher.
+     *
+     * A custom view is another rendering of the *same* `dataController`, so it
+     * inherits the toolbar's search, the loading state and selection. A
+     * component that fetches its own data does not want to be a view mode —
+     * the toolbar above it would be describing a query it does not render.
+     *
+     * @example
+     * ```tsx
+     * <CollectionView
+     *     customViews={{ map: { name: "Map", Component: MapView } }}
+     *     enabledViews={["table", "map"]}
+     *     defaultViewMode="map"
+     * />
+     * ```
+     */
+    customViews?: Record<string, CollectionCustomViewEntry<T>>;
+
     // ── Toolbar ───────────────────────────────────────────────────────
 
     /** Actions rendered at the start (left) of the toolbar */
@@ -215,6 +237,7 @@ export function CollectionView<T extends Record<string, unknown> = Record<string
     onMultipleDelete,
     cellRenderer,
     emptyComponent,
+    customViews,
     toolbarActionsStart,
     toolbarActionsEnd,
     hideToolbar,
@@ -298,7 +321,39 @@ export function CollectionView<T extends Record<string, unknown> = Record<string
         emptyComponent,
     };
 
+    // Resolved once so both the switcher and the render path agree. A custom
+    // view keyed as a built-in is ignored rather than allowed to shadow it —
+    // the switch below checks the built-ins first, so honouring such a key
+    // here would put the switcher and the canvas out of step.
+    const customViewEntries = useMemo(() => {
+        if (!customViews) return [];
+        return Object.entries(customViews)
+            .filter(([key]) => !DEFAULT_ENABLED_VIEWS.includes(key))
+            .map(([key, entry]) => {
+                const isBare = typeof entry === "function";
+                return {
+                    key,
+                    name: isBare ? key : (entry.name ?? key),
+                    icon: isBare ? undefined : entry.icon,
+                    Component: isBare ? entry : entry.Component
+                };
+            });
+    }, [customViews]);
+
     function renderView() {
+        const custom = customViewEntries.find((entry) => entry.key === viewMode);
+        if (custom) {
+            const { Component } = custom;
+            return (
+                <Component
+                    {...sharedProps}
+                    onRowCreate={canCreate ? onRowCreate : undefined}
+                    canCreate={canCreate}
+                    size={size}
+                />
+            );
+        }
+
         switch (viewMode) {
             case "table":
                 return (
@@ -372,6 +427,7 @@ export function CollectionView<T extends Record<string, unknown> = Record<string
                     viewMode={viewMode}
                     onViewModeChange={enabledViews.length > 1 ? onViewModeChange : undefined}
                     enabledViews={enabledViews}
+                    customViews={customViewEntries}
                     size={size}
                     onSizeChange={onSizeChange}
                     searchString={dataController.searchString}

package/src/views/CollectionView/CollectionViewToolbar.tsx

@@ -20,6 +20,12 @@ export type CollectionViewToolbarProps = {
     viewMode: CollectionViewMode;
     onViewModeChange?: (mode: CollectionViewMode) => void;
     enabledViews?: CollectionViewMode[];
+    /**
+     * Custom view modes, supplying the label and icon for their switcher
+     * entries. Without these an `enabledViews` key outside the four built-ins
+     * has no label and no icon to draw.
+     */
+    customViews?: { key: string, name: string, icon?: React.ReactNode }[];
     size?: CollectionViewSize;
     onSizeChange?: (size: CollectionViewSize) => void;
     searchString?: string;
@@ -33,14 +39,14 @@ export type CollectionViewToolbarProps = {
     onKanbanPropertyChange?: (property: string) => void;
 };
 
-const VIEW_MODE_ICONS: Record<CollectionViewMode, React.ReactNode> = {
+const VIEW_MODE_ICONS: Record<string, React.ReactNode> = {
     list: <LayoutList size={iconSize.small} />,
     table: <Table2 size={iconSize.small} />,
     cards: <LayoutGrid size={iconSize.small} />,
     kanban: <Kanban size={iconSize.small} />,
 };
 
-const VIEW_MODE_LABELS: Record<CollectionViewMode, string> = {
+const VIEW_MODE_LABELS: Record<string, string> = {
     list: "List",
     table: "Table",
     cards: "Cards",
@@ -67,6 +73,7 @@ export function CollectionViewToolbar({
     viewMode,
     onViewModeChange,
     enabledViews = ["list", "table", "cards", "kanban"],
+    customViews,
     size = "m",
     onSizeChange,
     searchString,
@@ -81,11 +88,17 @@ export function CollectionViewToolbar({
 }: CollectionViewToolbarProps) {
     const [popoverOpen, setPopoverOpen] = useState(false);
 
-    const viewOptions: ToggleButtonOption<CollectionViewMode>[] = enabledViews.map((mode) => ({
-        value: mode,
-        label: VIEW_MODE_LABELS[mode],
-        icon: VIEW_MODE_ICONS[mode],
-    }));
+    // A key outside the four built-ins takes its label and icon from the
+    // custom view that declared it; without one it falls back to the key
+    // itself and the list glyph, so an entry is never blank.
+    const viewOptions: ToggleButtonOption<CollectionViewMode>[] = enabledViews.map((mode) => {
+        const custom = customViews?.find((entry) => entry.key === mode);
+        return {
+            value: mode,
+            label: VIEW_MODE_LABELS[mode] ?? custom?.name ?? mode,
+            icon: VIEW_MODE_ICONS[mode] ?? custom?.icon ?? <LayoutList size={iconSize.small} />,
+        };
+    });
 
     const handleViewModeChange = useCallback(
         (mode: CollectionViewMode) => {

package/src/views/CollectionView/CollectionViewTypes.ts

@@ -1,8 +1,13 @@
 import React from "react";
 import type { VirtualTableSortKey } from "../../components/VirtualTable/VirtualTableProps";
 
-/** Supported view modes */
-export type CollectionViewMode = "table" | "cards" | "kanban" | "list";
+/**
+ * Supported view modes.
+ *
+ * Any other string is a key into the `customViews` prop. The `(string & {})`
+ * arm keeps the four built-ins in autocomplete while admitting those keys.
+ */
+export type CollectionViewMode = "table" | "cards" | "kanban" | "list" | (string & {});
 
 /** Supported collection sizes */
 export type CollectionViewSize = "xs" | "s" | "m" | "l" | "xl";
@@ -137,3 +142,40 @@ export interface KanbanPropertyOption {
     key: string;
     label: string;
 }
+
+/**
+ * What a custom view's component receives — the same set the built-in table,
+ * card, list and kanban views are given, so a custom view starts at parity
+ * with them and inherits the toolbar's search, the empty state and selection.
+ */
+export interface CollectionCustomViewProps<T = Record<string, unknown>> {
+    dataController: CollectionDataController<T>;
+    properties: Record<string, CollectionPropertyConfig>;
+    propertiesOrder?: string[];
+    idProperty?: string;
+    titleProperty?: string;
+    onRowClick?: (row: T) => void;
+    onRowCreate?: (defaults?: Record<string, unknown>) => void;
+    canCreate?: boolean;
+    cellRenderer?: CellRendererOverride<T>;
+    selectionEnabled?: boolean;
+    selectionController?: CollectionSelectionController<T>;
+    highlightedItems?: T[];
+    emptyComponent?: React.ReactNode;
+    size?: CollectionViewSize;
+}
+
+/**
+ * A custom view registration. Either the component on its own, or the
+ * component with the label and icon its switcher entry should carry.
+ *
+ * Without a `name` the switcher falls back to the key, which is legible but
+ * rarely what you want on screen.
+ */
+export type CollectionCustomViewEntry<T = Record<string, unknown>> =
+    | React.ComponentType<CollectionCustomViewProps<T>>
+    | {
+        name?: string;
+        icon?: React.ReactNode;
+        Component: React.ComponentType<CollectionCustomViewProps<T>>;
+    };