@carlonicora/nextjs-jsonapi 3.3.4 → 3.3.6

package/src/components/forms/DatePickerPopover.tsx

@@ -2,7 +2,7 @@
 
 import { isValid, parse } from "date-fns";
 import { Calendar as CalendarIcon, CircleXIcon } from "lucide-react";
-import { ReactNode, useMemo, useState } from "react";
+import { ReactElement, useMemo, useState } from "react";
 import { useI18nDateFnsLocale, useI18nLocale } from "../../i18n";
 import {
   Calendar,
@@ -19,7 +19,19 @@ import {
 import { cn } from "../../utils";
 
 type DatePickerPopoverProps = {
-  children: ReactNode;
+  /** MUST be a single element — it becomes the trigger element itself (see `render` below). */
+  children: ReactElement;
+  /**
+   * Whether the element passed as `children` is a real <button>.
+   *
+   * Base UI's trigger assumes it renders a native button. When `render` swaps
+   * in something else (a table cell's <div> wrapper), that assumption is wrong:
+   * native button semantics are lost and Base UI warns on every mount. Passing
+   * `false` makes it apply role="button" plus the keyboard handling itself, so
+   * a non-button trigger stays operable and accessible.
+   */
+  nativeButton?: boolean;
+
   value?: Date;
   onSelect: (date?: Date) => void;
   minDate?: Date;
@@ -29,6 +41,7 @@ type DatePickerPopoverProps = {
 
 export const DatePickerPopover = ({
   children,
+  nativeButton = true,
   value,
   onSelect,
   minDate,
@@ -126,7 +139,22 @@ export const DatePickerPopover = ({
 
   return (
     <Popover open={isOpen} onOpenChange={setIsOpen}>
-      <PopoverTrigger>{children}</PopoverTrigger>
+      {/*
+        `render`, NOT `<PopoverTrigger>{children}</PopoverTrigger>`. Base UI's
+        Popover.Trigger otherwise renders its OWN <button> WRAPPING the child
+        and binds the open handler to that button. Two consequences, both real:
+        - Table callers pass a cell wrapper whose onClick calls
+          stopPropagation() (so clicking the cell does not trigger the row's
+          navigation). Being the deeper element, its handler runs FIRST, the
+          click never bubbles to Base UI's button, and the popover could never
+          open — for mouse users as much as for tests.
+        - Form callers pass a <Button>, which the wrapper turned into a
+          <button> inside a <button>: invalid HTML and a hydration error.
+        With `render` the child IS the trigger, so the handlers share one
+        element (stopPropagation stops ANCESTOR propagation, not other handlers
+        on the same node) and no nested button is produced.
+      */}
+      <PopoverTrigger nativeButton={nativeButton} render={children} />
       <PopoverContent className={cn("p-0", className)} align={align} onClick={(e) => e.stopPropagation()}>
         <div className="p-3">
           {/* Manual Input */}

package/src/components/forms/DateRangeSelector.tsx

@@ -9,6 +9,39 @@ import { useI18nDateFnsLocale } from "../../i18n";
 import { Button, Calendar, Popover, PopoverContent, PopoverTrigger } from "../../shadcnui";
 import { cn } from "../../utils";
 
+/**
+ * Decides the range to hold after react-day-picker reports a selection.
+ *
+ * react-day-picker's `addToRange` NEVER moves `from` when the current range is
+ * already COMPLETE and the clicked day falls after it — it returns
+ * `{ from, to: clickedDay }` (see its `from && to` branch). So "did `from`
+ * change?" cannot distinguish "the user is starting a new range" from "the user
+ * moved the end": it is true only for a click BEFORE `from`.
+ *
+ * That is the asymmetry this component shipped with. Its default range is the
+ * whole CURRENT month, so clicking any day in the current month landed after
+ * `from` and silently became the END date — the start could never be moved
+ * forward — while clicking a day in a PAST month fell before `from`, changed it,
+ * and appeared to work.
+ *
+ * A click on a complete range therefore starts a NEW range at the clicked day,
+ * which is the conventional range-picker behaviour. `triggerDate` is the day
+ * react-day-picker reports as the one that was clicked (`onSelect`'s second
+ * argument) — the only reliable source for it, since the computed range hides it.
+ */
+export function nextDateRange(params: {
+  current: DateRange | undefined;
+  computed: DateRange | undefined;
+  triggerDate: Date;
+}): DateRange | undefined {
+  const { current, computed, triggerDate } = params;
+  // react-day-picker returns undefined to DESELECT (clicking the only selected
+  // day of a single-day range). Honour that before anything else.
+  if (!computed) return undefined;
+  if (current?.from && current?.to) return { from: triggerDate, to: undefined };
+  return computed;
+}
+
 type DateRangeSelectorProps = {
   onDateChange: (date?: DateRange) => void;
   avoidSettingDates?: boolean;
@@ -49,18 +82,9 @@ export function DateRangeSelector({ onDateChange, avoidSettingDates, showPreviou
     }
   }, [date, prevRange, onDateChange]);
 
-  // Custom handler to reset end date if a new start date is picked
-  const handleSelect = (range: DateRange | undefined) => {
-    if (!range) {
-      setDate(undefined);
-      return;
-    }
-    // If a new start date is picked, reset end date
-    if (range.from && (!date?.from || range.from.getTime() !== date.from.getTime())) {
-      setDate({ from: range.from, to: undefined });
-    } else {
-      setDate(range);
-    }
+  // A click on an already-complete range starts a new one — see nextDateRange().
+  const handleSelect = (range: DateRange | undefined, triggerDate: Date) => {
+    setDate(nextDateRange({ current: date, computed: range, triggerDate }));
   };
 
   // Show placeholder button during SSR to prevent hydration mismatch

package/src/components/forms/__tests__/DateRangeSelector.spec.ts

@@ -0,0 +1,74 @@
+import { describe, expect, it } from "vitest";
+import { nextDateRange } from "../DateRangeSelector";
+
+// The dates below mirror the component's own default range: the whole current
+// month. "Today" is irrelevant to nextDateRange() — only the shape of the range
+// matters — so fixed dates are used rather than a faked clock.
+const AUG_1 = new Date(2026, 7, 1);
+const AUG_10 = new Date(2026, 7, 10);
+const AUG_20 = new Date(2026, 7, 20);
+const AUG_31 = new Date(2026, 7, 31);
+const JUL_10 = new Date(2026, 6, 10);
+
+const CURRENT_MONTH = { from: AUG_1, to: AUG_31 };
+
+describe("nextDateRange", () => {
+  // The reported bug: with the default (complete) current-month range, every
+  // click in the current month lands AFTER `from`, so react-day-picker returns
+  // { from: AUG_1, to: clicked } and `from` never moves. The selector must read
+  // that as "start a new range at the clicked day", not "move the end".
+  it("starts a new range when a complete range is clicked inside the current month", () => {
+    expect(
+      nextDateRange({
+        current: CURRENT_MONTH,
+        computed: { from: AUG_1, to: AUG_10 }, // what addToRange returns
+        triggerDate: AUG_10,
+      }),
+    ).toEqual({ from: AUG_10, to: undefined });
+  });
+
+  // The half that always worked, and which must keep working: a click BEFORE
+  // `from` does move `from`, so react-day-picker returns { from: clicked, to }.
+  // Same outcome either way — the clicked day becomes the new start.
+  it("starts a new range when a complete range is clicked in a past month", () => {
+    expect(
+      nextDateRange({
+        current: CURRENT_MONTH,
+        computed: { from: JUL_10, to: AUG_31 },
+        triggerDate: JUL_10,
+      }),
+    ).toEqual({ from: JUL_10, to: undefined });
+  });
+
+  it("completes an in-progress range with the second click", () => {
+    expect(
+      nextDateRange({
+        current: { from: AUG_10, to: undefined },
+        computed: { from: AUG_10, to: AUG_20 },
+        triggerDate: AUG_20,
+      }),
+    ).toEqual({ from: AUG_10, to: AUG_20 });
+  });
+
+  it("keeps react-day-picker's swap when the second click precedes the start", () => {
+    expect(
+      nextDateRange({
+        current: { from: AUG_20, to: undefined },
+        computed: { from: AUG_10, to: AUG_20 },
+        triggerDate: AUG_10,
+      }),
+    ).toEqual({ from: AUG_10, to: AUG_20 });
+  });
+
+  it("opens a range from the empty state", () => {
+    expect(
+      nextDateRange({ current: undefined, computed: { from: AUG_10, to: AUG_10 }, triggerDate: AUG_10 }),
+    ).toEqual({ from: AUG_10, to: AUG_10 });
+  });
+
+  // react-day-picker returns undefined to DESELECT; that must survive the
+  // complete-range branch rather than being turned into a new start.
+  it("clears when react-day-picker deselects", () => {
+    expect(nextDateRange({ current: { from: AUG_10, to: AUG_10 }, computed: undefined, triggerDate: AUG_10 })).toBeUndefined();
+  });
+});