react-native-modal-datetime-picker

react-native-modal-datetime-picker gives React Native apps a single, cross-platform date and time picker component instead of hand-rolling separate iOS and Android pickers. It wraps @react-native-community/datetimepicker — the underlying platform picker — in a slide-up modal on iOS and a native dialog flow on Android, exposing one consistent isVisible/onConfirm/onCancel API regardless of platform.

The library has been a staple of the React Native ecosystem for years, with 3,000+ GitHub stars and hundreds of thousands of weekly npm downloads, and works out of the box with both bare React Native and Expo-managed projects. It supports date, time, and combined datetime modes, minimum/maximum date constraints, custom iOS confirm/cancel buttons and headers, and dark mode detection via the Appearance API.

What You Get

• A single DateTimePickerModal component that renders the right native picker UI on iOS and Android from one shared prop API.
• Support for date, time, and combined datetime picker modes, with minimum/maximum date constraints passed straight through to the native picker.
• iOS-specific customization props (custom cancel/confirm buttons, custom header, custom picker component, and per-element style overrides) for matching an app’s design system.
• Automatic light/dark mode detection on iOS via the Appearance API, with a manual isDarkModeEnabled override.
• Full TypeScript type definitions shipped separately in typings/index.d.ts.

Common Use Cases

• Letting users pick a birthdate or appointment date in a form without building custom native picker UI per platform.
• Scheduling reminders or bookings that require both a date and a time value.
• Filtering a list or search by a date range using minimumDate/maximumDate constraints.
• Building forms in Expo-managed apps where installing bare native picker modules isn’t an option.

Under The Hood

Architecture The library exports a default component from src/index.js that resolves to platform-specific implementations via React Native’s automatic file-extension resolution (DateTimePickerModal.ios.js and DateTimePickerModal.android.js), with a shared DateTimePickerModal.js facade for other platforms. The iOS implementation wraps the native picker inside a custom slide-up Modal component (src/Modal.js) that manages its own visibility state and Animated-driven slide transitions, decoupling presentation chrome from the underlying @react-native-community/datetimepicker component. The Android implementation is comparatively thin, directly rendering the native picker dialog with a two-phase state machine (cycling currentMode between “date” and “time” for the “datetime” mode) since Android’s native picker already provides its own modal chrome. Cross-cutting concerns like iPhone X notch-safe bottom margins live in src/utils.js. There’s no dependency injection or complex data flow — state flows top-down via props into two isolated platform branches — and a change to the wrapped picker’s event shape would ripple through both the iOS Modal wrapping logic and the Android mode state machine, since both hard-code assumptions about it.

Tech Stack Written in plain JavaScript (not TypeScript) with hand-maintained type definitions shipped separately in typings/index.d.ts. The only runtime dependency is prop-types, with react, react-native, and @react-native-community/datetimepicker (>=6.7.0) declared as peers. No bundler or transpilation step is shipped — consumers get the raw src/ files, compiled by their own app’s Metro/Babel pipeline. Linting uses ESLint with eslint-plugin-react-app and eslint-config-prettier; releases are fully automated via semantic-release triggered on push to master. The example/ directory is a full standalone React Native app (with its own iOS/Android native projects) used for manual visual testing rather than automated testing.

Code Quality There are no unit or integration tests for the JS logic — package.json’s “test” script is an alias for “yarn run lint”, and CI’s “Lint & Test” workflow only runs that lint pass; the only real tests in the repo are native iOS smoke tests under example/ios/ExampleTests, which don’t exercise the library’s JS logic at all. Error handling is minimal and implicit in places — for example, Modal.js assumes its device-event-emitter reference is always set when unmounting, with no defensive check. Naming is consistent and readable throughout, PropTypes provide light runtime type-checking, and Prettier plus ESLint enforce consistent formatting, but there’s no static type safety on the implementation itself since the source is untyped JS.

API Design The public API surface is intentionally small: the default DateTimePickerModal component needs only isVisible, date, mode, onConfirm, and onCancel for a working picker, with every other prop purely additive and optional. Naming is consistent — onConfirm/onCancel/onHide/onChange mirror the underlying picker’s own event names — and the *IOS-suffixed prop convention (cancelTextIOS, pickerStyleIOS, buttonTextColorIOS) makes it immediately clear which props only affect one platform. Documentation is thorough for a project this size, with a full props table, a runnable usage snippet, and an extensive FAQ addressing real reported issues, but the additional named exports (CancelButton, ConfirmButton, cancelButtonStyles, confirmButtonStyles) are undocumented in the README despite being part of the public typings.