react-daterange-picker

A fully customizable, accessible date range picker component for React apps, with no moment.js dependency.

Library
npm
v7.1.0
565stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
64/100Good
Development Activity60
Maintenance60
Community48
Maturity60
Momentum28

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
78/100Good
Architecture78
Code Quality88
Innovation80
Learning Curve65

@wojtekmaj/react-daterange-picker is a lightweight date range picker component for React. It renders paired day/month/year (or native) inputs alongside a calendar dropdown built on the author’s own React-Calendar, letting users type a range directly or pick it visually, with locale-aware formatting via the native Intl API instead of moment.js or date-fns.

The component is highly configurable: custom min/max dates, per-detail-level views (month/year/decade/century), open/close lifecycle hooks, portal rendering, and full control over icons and ARIA labels for accessibility. It ships as ESM with TypeScript types, and is part of a small monorepo alongside React-Calendar, React-Date-Picker, and React-Time-Picker, maintained by the same author across all four and sharing conventions and internals.

What You Get

  • Combined typed inputs (day/month/year or native <input type=date>) synced to a dropdown calendar for range selection
  • Locale-aware formatting via the native Intl API — no moment.js or date-fns dependency
  • Fine-grained control over open/close behavior via shouldOpenCalendar/shouldCloseCalendar callbacks and lifecycle hooks
  • Full TypeScript types and a tree-shakeable ESM build with CSS shipped separately for custom theming

Common Use Cases

  • Booking and reservation forms that need a check-in to check-out range input
  • Analytics dashboards letting users filter a report by a custom date range
  • Admin panels and CRMs where filtering records by a date window is a core interaction
  • Travel and event-planning apps collecting start/end dates for trips or bookings

Under The Hood

Architecture The entire component lives in a single ~700-line file (DateRangePicker.tsx) that composes three sibling packages from the same monorepo: react-date-picker’s DateInput for the typed from/to fields, react-calendar for the dropdown grid, and react-fit to position the popover. State is local — a single isOpen boolean kept in sync with an optional controlled prop — and open/close/outside-click/escape-key behavior is centralized through a handful of useCallback-memoized handlers wired up in one useEffect keyed on isOpen. There is no Redux, context, or dependency injection; shared types live in src/shared/types.ts. The design is a thin, well-contained wrapper rather than a layered system, trading architectural depth for a small, auditable surface area.

Tech Stack Built on TypeScript targeting React 16 through 19 as peer dependencies, using clsx for conditional class names and make-event-props to spread arbitrary DOM event handlers onto the root element. It depends on its own sibling packages (react-calendar, react-date-picker, react-fit) rather than third-party equivalents. The monorepo uses Yarn 4 workspaces with PnP, Biome for combined linting and formatting (replacing ESLint/Prettier), and Vitest 4 with @vitest/browser-playwright and vitest-browser-react for real-browser (not jsdom-mocked) component tests. Releases publish via a GitHub Actions workflow using npm provenance and OIDC.

Code Quality The test suite (DateRangePicker.spec.tsx, ~940 lines) exercises real browser rendering with Playwright rather than DOM simulation, covering prop wiring, custom naming, form integration, ARIA labels, and keyboard interactions like escape-to-close. CI runs Biome lint, tsc, format checks, and the full Vitest suite on every push. Every public prop carries a JSDoc block with @default and @example annotations, giving strong IDE-level documentation alongside strict typing throughout.

API Design The prop-level JSDoc (defaults and examples on nearly every prop) gives editor tooltips that double as inline documentation without leaving the code. Sensible defaults mean the component works with zero configuration, while escape hatches like shouldOpenCalendar/shouldCloseCalendar predicate callbacks let consumers override open/close behavior without reimplementing the underlying state machine. The README’s own “Consider native alternative” section, pointing users toward a plain <input type=date> pair when advanced features aren’t needed, is an unusually candid piece of guidance from a library author about when not to reach for their own package.

Used by 5 apps in this directory

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search