@crispy-seed/data-table 0.10.4 → 0.10.5

package/dist/index.cjs

@@ -1696,24 +1696,33 @@ function useDataTableSort(props) {
         // already passes its "cleared" shape through unconditionally; this now matches.
         onChange: onSortChange
     });
+    // 3-state cycle (DATATABLE-ATTIO-SPEC.md: "asc/desc/none cycle") -- clicking a
+    // DIFFERENT column always starts it fresh at asc, discarding whatever the previous
+    // column's direction was (this stays a SINGLE-column secondary affordance, never a
+    // second multi-sort list of its own). Clicking the SAME column steps asc -> desc ->
+    // undefined ("none", i.e. this column drops out of the sort entirely) -> asc again.
+    // Before this, the cycle wrapped desc -> asc forever, with no click-driven way back
+    // to unsorted at all (a reported gap: "sort asc/desc has no option for no sort on
+    // columns") -- `clearSort` below was the ONLY way there, now it's one of two.
     const toggleSort = React.useCallback((key)=>{
         setSort((current)=>{
             if (!current || current.key !== key) return {
                 key,
                 dir: "asc"
             };
-            return {
+            if (current.dir === "asc") return {
                 key,
-                dir: current.dir === "asc" ? "desc" : "asc"
+                dir: "desc"
             };
+            return undefined;
         });
     }, [
         setSort
     ]);
-    /** Attio/GRC's "Remove sort" -- the header click cycle (above) only ever toggles
-   *  asc/desc once a column has been clicked once; this is the only way back to no
-   *  sort at all. Exposed for a column's own header menu (`column-menu.tsx`'s
-   *  `ColumnMenu`) to offer as a "Clear sort" item when that column is the sorted one. */ const clearSort = React.useCallback(()=>setSort(undefined), [
+    /** Attio/GRC's "Remove sort" -- a second way back to no sort at all (the header
+   *  click cycle above reaches it too, on a column's third click), exposed for a
+   *  column's own header menu (`column-menu.tsx`'s `ColumnMenu`) to offer as a
+   *  "Clear sort" item when that column is the sorted one, without three clicks. */ const clearSort = React.useCallback(()=>setSort(undefined), [
         setSort
     ]);
     const getHeaderCellProps = React.useCallback((columnKey, sortable)=>{
@@ -1746,7 +1755,12 @@ function useDataTableSort(props) {
         sort,
         toggleSort,
         clearSort,
-        getHeaderCellProps
+        getHeaderCellProps,
+        // Exposed for `useDataTable.ts`'s own composition ONLY (unifying this single
+        // click-to-sort column with `useDataTableToolbarSort`'s ordered list) -- not part
+        // of the documented header-click contract (`toggleSort`/`clearSort` above are),
+        // so no consumer-facing doc comment promotes it as a control of its own.
+        setSort
     };
 }
 
@@ -1850,11 +1864,14 @@ const EMPTY_SORTS = [];
  * concern rather than folded into `useDataTableSort` (DATATABLE-ATTIO-SPEC.md: "compose,
  * don't fatten one hook"). `useDataTableSort` still owns the single click-to-sort
  * column/direction a header's own click toggles -- that stays Attio's SECONDARY sort
- * affordance, untouched by this hook. This one is the PRIMARY toolbar Sort control: add
- * a condition, pick its field/direction, reorder, remove -- multiple conditions apply in
- * list order (sort[0] wins, later ones break ties; see the styled layer's
- * `applyToolbarSorts`). The styled layer decides how the two combine (DataTable.tsx:
- * toolbar sorts win when any exist, the single click-to-sort column otherwise).
+ * affordance, a separate hook from this one. They are NOT independent state, though:
+ * `useDataTable.ts`'s own composition keeps a header-driven column's entry in THIS
+ * array in sync (added/updated/removed as that column's header cycles asc/desc/none),
+ * so a consumer controlling only `toolbarSorts`/`onToolbarSortsChange` still sees a
+ * header click, and the toolbar's own "Remove sort" x on that same entry clears the
+ * header's side too. Multiple conditions apply in list order (sort[0] wins, later ones
+ * break ties; see the styled layer's `applyToolbarSorts`). The styled layer
+ * (`DataTable.tsx`) decides how the merged result actually sorts `data`.
  */ function useDataTableToolbarSort(props) {
     const { toolbarSorts: sortsProp, defaultToolbarSorts = EMPTY_SORTS, onToolbarSortsChange } = props;
     const [toolbarSorts = EMPTY_SORTS, setToolbarSorts] = useControllableState$1({
@@ -1939,8 +1956,13 @@ const EMPTY_SORTS = [];
 // header "is/is not" picker) -- DATATABLE-ATTIO-SPEC.md's Attio/crisp `TableToolbar`
 // model is now the PRIMARY filter/sort UX, not a per-column header affordance. They stay
 // SEPARATE sub-hooks from `useDataTableSort` rather than folded into it ("compose, don't
-// fatten one hook") -- the styled layer decides how the toolbar's multi-condition sort
-// and the header's single click-to-sort combine (DataTable.tsx).
+// fatten one hook") -- but this composition point below DOES reconcile the two into one
+// state (the two `useEffect`s after `infiniteScroll`), so a header click and the
+// toolbar's own Sort popover always agree on what's sorted, regardless of which prop
+// pair (`sort`/`onSortChange` or `toolbarSorts`/`onToolbarSortsChange`) a consumer
+// actually controls. `DataTable.tsx` (styled) still decides how the RESULT actually
+// sorts `data` (`effectiveSorts`/`applyToolbarSorts`) -- this layer only keeps the two
+// STATE pools in agreement.
 function useDataTable(props) {
     const sort = useDataTableSort(props);
     const selection = useDataTableSelection(props);
@@ -1963,6 +1985,105 @@ function useDataTable(props) {
         ...props,
         scrollRootRef: scroll.elementRef
     });
+    // Unifies `sort` (the header's own single click-to-sort column, above) with
+    // `toolbarSort.toolbarSorts` (the toolbar Sort popover's ordered list, above) into
+    // ONE state instead of two -- before this, a header click only ever moved `sort`,
+    // invisible to a consumer controlling `toolbarSorts`/`onToolbarSortsChange` (the
+    // reported bug: clicking a header did nothing to the array the consumer's own Sort
+    // popover reads, so the toolbar's "Sort" trigger/count and its popover rows silently
+    // ignored every header click).
+    //
+    // ONE effect, not two -- an earlier version split this into a forward
+    // (`sort` -> `toolbarSorts`) and a reverse (`toolbarSorts` -> `sort`) effect, each
+    // keyed off its own dependency. That raced on the very first render: `useEffect`
+    // runs every effect once on mount regardless of what "changed", so with
+    // `defaultSort` set, the reverse effect ran in the SAME commit as the forward one,
+    // read `toolbarSorts` BEFORE the forward effect's own (still-queued, not yet
+    // re-rendered) write had landed, saw no entry for the column yet, and immediately
+    // cleared `sort` right back out -- the defaultSort silently never took effect.
+    // `settledRef` sidesteps this: it remembers the last `{key,dir}` this effect itself
+    // confirmed, so on every run it can tell WHICH side moved since then, instead of
+    // guessing from which dependency happens to have triggered the re-run.
+    const settledRef = React.useRef({
+        key: undefined,
+        dir: undefined
+    });
+    React.useEffect(()=>{
+        const curSort = sort.sort;
+        const curEntry = curSort ? toolbarSort.toolbarSorts.find((s)=>s.key === curSort.key) : undefined;
+        const settled = settledRef.current;
+        const sortUnchangedSinceSettled = settled.key === curSort?.key && settled.dir === curSort?.dir;
+        if (sortUnchangedSinceSettled) {
+            // `sort` itself hasn't moved since we last settled -- if this effect is running
+            // at all, `toolbarSorts` is what changed, so REVERSE-sync: the toolbar Sort
+            // popover's own "Remove sort" x, or its direction select, touching this exact
+            // column. Never reaches across to adopt some OTHER column added independently
+            // via that popover -- only the column `sort` is already tracking.
+            if (!curSort) return;
+            if (!curEntry) {
+                sort.clearSort();
+                settledRef.current = {
+                    key: undefined,
+                    dir: undefined
+                };
+            } else if (curEntry.dir !== curSort.dir) {
+                sort.setSort({
+                    key: curSort.key,
+                    dir: curEntry.dir
+                });
+                settledRef.current = {
+                    key: curSort.key,
+                    dir: curEntry.dir
+                };
+            }
+            return;
+        }
+        // `sort` moved (a header click, Enter/Space, or `clearSort` -- column-menu.tsx's
+        // menu item calls that directly, bypassing `toggleSort`) -- FORWARD-sync:
+        // add/update/remove THIS column's own entry in `toolbarSorts`, leaving every
+        // OTHER entry (added independently via the toolbar's own "+ Add sort") untouched.
+        // The functional updater reads the CURRENT array off `current`, never off
+        // `toolbarSort.toolbarSorts` in this closure, so a stale render can never clobber
+        // an entry the toolbar's own popover added a moment earlier.
+        const prevKey = settled.key;
+        toolbarSort.setToolbarSorts((current)=>{
+            let updated = current;
+            if (prevKey && prevKey !== curSort?.key) {
+                updated = updated.filter((s)=>s.key !== prevKey);
+            }
+            if (curSort) {
+                const idx = updated.findIndex((s)=>s.key === curSort.key);
+                if (idx === -1) {
+                    updated = [
+                        ...updated,
+                        {
+                            key: curSort.key,
+                            dir: curSort.dir
+                        }
+                    ];
+                } else if (updated[idx].dir !== curSort.dir) {
+                    updated = updated.map((s, i)=>i === idx ? {
+                            ...s,
+                            dir: curSort.dir
+                        } : s);
+                }
+            }
+            return updated;
+        });
+        settledRef.current = curSort ? {
+            key: curSort.key,
+            dir: curSort.dir
+        } : {
+            key: undefined,
+            dir: undefined
+        };
+    }, [
+        sort.sort,
+        toolbarSort.toolbarSorts,
+        toolbarSort.setToolbarSorts,
+        sort.clearSort,
+        sort.setSort
+    ]);
     return {
         ...sort,
         ...selection,
@@ -5400,9 +5521,9 @@ function ColumnRenameInput({ column, initialLabel, onDone }) {
     const columnLabel = typeof label === "string" ? label : column.key;
     const pinned = isColumnPinned(column.key);
     // Attio/GRC's "Remove sort" (live-review fix D) -- the header's own click-to-sort
-    // (`SortIndicator`/`toggleSort`, above) only cycles asc/desc once a column has been
-    // clicked; this is the only affordance back to no sort at all, so it only makes
-    // sense to show on the column that IS currently sorted.
+    // (`SortIndicator`/`toggleSort`, above) already cycles asc -> desc -> none on its
+    // own third click, but this stays as a one-click shortcut to the same place, so it
+    // only makes sense to show on the column that IS currently sorted.
     const isSorted = sort?.key === column.key;
     const stopPropagation = (event)=>event.stopPropagation();
     return(// Live-review fix (D): a `MenuItem` inside `MenuPositioner` renders through a

package/dist/index.js

@@ -1677,24 +1677,33 @@ function useDataTableSort(props) {
         // already passes its "cleared" shape through unconditionally; this now matches.
         onChange: onSortChange
     });
+    // 3-state cycle (DATATABLE-ATTIO-SPEC.md: "asc/desc/none cycle") -- clicking a
+    // DIFFERENT column always starts it fresh at asc, discarding whatever the previous
+    // column's direction was (this stays a SINGLE-column secondary affordance, never a
+    // second multi-sort list of its own). Clicking the SAME column steps asc -> desc ->
+    // undefined ("none", i.e. this column drops out of the sort entirely) -> asc again.
+    // Before this, the cycle wrapped desc -> asc forever, with no click-driven way back
+    // to unsorted at all (a reported gap: "sort asc/desc has no option for no sort on
+    // columns") -- `clearSort` below was the ONLY way there, now it's one of two.
     const toggleSort = useCallback((key)=>{
         setSort((current)=>{
             if (!current || current.key !== key) return {
                 key,
                 dir: "asc"
             };
-            return {
+            if (current.dir === "asc") return {
                 key,
-                dir: current.dir === "asc" ? "desc" : "asc"
+                dir: "desc"
             };
+            return undefined;
         });
     }, [
         setSort
     ]);
-    /** Attio/GRC's "Remove sort" -- the header click cycle (above) only ever toggles
-   *  asc/desc once a column has been clicked once; this is the only way back to no
-   *  sort at all. Exposed for a column's own header menu (`column-menu.tsx`'s
-   *  `ColumnMenu`) to offer as a "Clear sort" item when that column is the sorted one. */ const clearSort = useCallback(()=>setSort(undefined), [
+    /** Attio/GRC's "Remove sort" -- a second way back to no sort at all (the header
+   *  click cycle above reaches it too, on a column's third click), exposed for a
+   *  column's own header menu (`column-menu.tsx`'s `ColumnMenu`) to offer as a
+   *  "Clear sort" item when that column is the sorted one, without three clicks. */ const clearSort = useCallback(()=>setSort(undefined), [
         setSort
     ]);
     const getHeaderCellProps = useCallback((columnKey, sortable)=>{
@@ -1727,7 +1736,12 @@ function useDataTableSort(props) {
         sort,
         toggleSort,
         clearSort,
-        getHeaderCellProps
+        getHeaderCellProps,
+        // Exposed for `useDataTable.ts`'s own composition ONLY (unifying this single
+        // click-to-sort column with `useDataTableToolbarSort`'s ordered list) -- not part
+        // of the documented header-click contract (`toggleSort`/`clearSort` above are),
+        // so no consumer-facing doc comment promotes it as a control of its own.
+        setSort
     };
 }
 
@@ -1831,11 +1845,14 @@ const EMPTY_SORTS = [];
  * concern rather than folded into `useDataTableSort` (DATATABLE-ATTIO-SPEC.md: "compose,
  * don't fatten one hook"). `useDataTableSort` still owns the single click-to-sort
  * column/direction a header's own click toggles -- that stays Attio's SECONDARY sort
- * affordance, untouched by this hook. This one is the PRIMARY toolbar Sort control: add
- * a condition, pick its field/direction, reorder, remove -- multiple conditions apply in
- * list order (sort[0] wins, later ones break ties; see the styled layer's
- * `applyToolbarSorts`). The styled layer decides how the two combine (DataTable.tsx:
- * toolbar sorts win when any exist, the single click-to-sort column otherwise).
+ * affordance, a separate hook from this one. They are NOT independent state, though:
+ * `useDataTable.ts`'s own composition keeps a header-driven column's entry in THIS
+ * array in sync (added/updated/removed as that column's header cycles asc/desc/none),
+ * so a consumer controlling only `toolbarSorts`/`onToolbarSortsChange` still sees a
+ * header click, and the toolbar's own "Remove sort" x on that same entry clears the
+ * header's side too. Multiple conditions apply in list order (sort[0] wins, later ones
+ * break ties; see the styled layer's `applyToolbarSorts`). The styled layer
+ * (`DataTable.tsx`) decides how the merged result actually sorts `data`.
  */ function useDataTableToolbarSort(props) {
     const { toolbarSorts: sortsProp, defaultToolbarSorts = EMPTY_SORTS, onToolbarSortsChange } = props;
     const [toolbarSorts = EMPTY_SORTS, setToolbarSorts] = useControllableState$1({
@@ -1920,8 +1937,13 @@ const EMPTY_SORTS = [];
 // header "is/is not" picker) -- DATATABLE-ATTIO-SPEC.md's Attio/crisp `TableToolbar`
 // model is now the PRIMARY filter/sort UX, not a per-column header affordance. They stay
 // SEPARATE sub-hooks from `useDataTableSort` rather than folded into it ("compose, don't
-// fatten one hook") -- the styled layer decides how the toolbar's multi-condition sort
-// and the header's single click-to-sort combine (DataTable.tsx).
+// fatten one hook") -- but this composition point below DOES reconcile the two into one
+// state (the two `useEffect`s after `infiniteScroll`), so a header click and the
+// toolbar's own Sort popover always agree on what's sorted, regardless of which prop
+// pair (`sort`/`onSortChange` or `toolbarSorts`/`onToolbarSortsChange`) a consumer
+// actually controls. `DataTable.tsx` (styled) still decides how the RESULT actually
+// sorts `data` (`effectiveSorts`/`applyToolbarSorts`) -- this layer only keeps the two
+// STATE pools in agreement.
 function useDataTable(props) {
     const sort = useDataTableSort(props);
     const selection = useDataTableSelection(props);
@@ -1944,6 +1966,105 @@ function useDataTable(props) {
         ...props,
         scrollRootRef: scroll.elementRef
     });
+    // Unifies `sort` (the header's own single click-to-sort column, above) with
+    // `toolbarSort.toolbarSorts` (the toolbar Sort popover's ordered list, above) into
+    // ONE state instead of two -- before this, a header click only ever moved `sort`,
+    // invisible to a consumer controlling `toolbarSorts`/`onToolbarSortsChange` (the
+    // reported bug: clicking a header did nothing to the array the consumer's own Sort
+    // popover reads, so the toolbar's "Sort" trigger/count and its popover rows silently
+    // ignored every header click).
+    //
+    // ONE effect, not two -- an earlier version split this into a forward
+    // (`sort` -> `toolbarSorts`) and a reverse (`toolbarSorts` -> `sort`) effect, each
+    // keyed off its own dependency. That raced on the very first render: `useEffect`
+    // runs every effect once on mount regardless of what "changed", so with
+    // `defaultSort` set, the reverse effect ran in the SAME commit as the forward one,
+    // read `toolbarSorts` BEFORE the forward effect's own (still-queued, not yet
+    // re-rendered) write had landed, saw no entry for the column yet, and immediately
+    // cleared `sort` right back out -- the defaultSort silently never took effect.
+    // `settledRef` sidesteps this: it remembers the last `{key,dir}` this effect itself
+    // confirmed, so on every run it can tell WHICH side moved since then, instead of
+    // guessing from which dependency happens to have triggered the re-run.
+    const settledRef = useRef({
+        key: undefined,
+        dir: undefined
+    });
+    useEffect(()=>{
+        const curSort = sort.sort;
+        const curEntry = curSort ? toolbarSort.toolbarSorts.find((s)=>s.key === curSort.key) : undefined;
+        const settled = settledRef.current;
+        const sortUnchangedSinceSettled = settled.key === curSort?.key && settled.dir === curSort?.dir;
+        if (sortUnchangedSinceSettled) {
+            // `sort` itself hasn't moved since we last settled -- if this effect is running
+            // at all, `toolbarSorts` is what changed, so REVERSE-sync: the toolbar Sort
+            // popover's own "Remove sort" x, or its direction select, touching this exact
+            // column. Never reaches across to adopt some OTHER column added independently
+            // via that popover -- only the column `sort` is already tracking.
+            if (!curSort) return;
+            if (!curEntry) {
+                sort.clearSort();
+                settledRef.current = {
+                    key: undefined,
+                    dir: undefined
+                };
+            } else if (curEntry.dir !== curSort.dir) {
+                sort.setSort({
+                    key: curSort.key,
+                    dir: curEntry.dir
+                });
+                settledRef.current = {
+                    key: curSort.key,
+                    dir: curEntry.dir
+                };
+            }
+            return;
+        }
+        // `sort` moved (a header click, Enter/Space, or `clearSort` -- column-menu.tsx's
+        // menu item calls that directly, bypassing `toggleSort`) -- FORWARD-sync:
+        // add/update/remove THIS column's own entry in `toolbarSorts`, leaving every
+        // OTHER entry (added independently via the toolbar's own "+ Add sort") untouched.
+        // The functional updater reads the CURRENT array off `current`, never off
+        // `toolbarSort.toolbarSorts` in this closure, so a stale render can never clobber
+        // an entry the toolbar's own popover added a moment earlier.
+        const prevKey = settled.key;
+        toolbarSort.setToolbarSorts((current)=>{
+            let updated = current;
+            if (prevKey && prevKey !== curSort?.key) {
+                updated = updated.filter((s)=>s.key !== prevKey);
+            }
+            if (curSort) {
+                const idx = updated.findIndex((s)=>s.key === curSort.key);
+                if (idx === -1) {
+                    updated = [
+                        ...updated,
+                        {
+                            key: curSort.key,
+                            dir: curSort.dir
+                        }
+                    ];
+                } else if (updated[idx].dir !== curSort.dir) {
+                    updated = updated.map((s, i)=>i === idx ? {
+                            ...s,
+                            dir: curSort.dir
+                        } : s);
+                }
+            }
+            return updated;
+        });
+        settledRef.current = curSort ? {
+            key: curSort.key,
+            dir: curSort.dir
+        } : {
+            key: undefined,
+            dir: undefined
+        };
+    }, [
+        sort.sort,
+        toolbarSort.toolbarSorts,
+        toolbarSort.setToolbarSorts,
+        sort.clearSort,
+        sort.setSort
+    ]);
     return {
         ...sort,
         ...selection,
@@ -5381,9 +5502,9 @@ function ColumnRenameInput({ column, initialLabel, onDone }) {
     const columnLabel = typeof label === "string" ? label : column.key;
     const pinned = isColumnPinned(column.key);
     // Attio/GRC's "Remove sort" (live-review fix D) -- the header's own click-to-sort
-    // (`SortIndicator`/`toggleSort`, above) only cycles asc/desc once a column has been
-    // clicked; this is the only affordance back to no sort at all, so it only makes
-    // sense to show on the column that IS currently sorted.
+    // (`SortIndicator`/`toggleSort`, above) already cycles asc -> desc -> none on its
+    // own third click, but this stays as a one-click shortcut to the same place, so it
+    // only makes sense to show on the column that IS currently sorted.
     const isSorted = sort?.key === column.key;
     const stopPropagation = (event)=>event.stopPropagation();
     return(// Live-review fix (D): a `MenuItem` inside `MenuPositioner` renders through a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@crispy-seed/data-table",
-  "version": "0.10.4",
+  "version": "0.10.5",
   "description": "Self-contained, publishable build of seed-design's Attio-measured DataTable, ResizablePanel and RecordPreview — one install, one CSS import.",
   "repository": {
     "type": "git",