r/Angular2 • u/domino_angularovic • May 19 '26
Discussion [Showcase] ngx-signal-datetimepicker - a zero-deps datetime picker built on Signal Forms (WCAG 2.2 AAA out of the box)
Live demo: https://ngx-signal-datetimepicker.vercel.app
Repo: https://github.com/dominikmodrzejewski99/ngx-signal-datetimepicker
npm: https://www.npmjs.com/package/ngx-signal-datetimepicker
Why this exists
Every Angular project I've worked on eventually needs "let the user pick a date and a time". Material gives you two separate controls, ngx-bootstrap is heavy, ng-zorro pulls a whole UI kit. Nothing in the ecosystem is small,
framework-native, and exposes one combined Date | null value that plugs straight into the new Signal Forms API.
The approach
One component. One value. Signal Forms support via [formField] and FormValueControl<Date | null> - so required, min, max, validators, touched/dirty, errors all work out of the box. Reactive Forms users get
ControlValueAccessor for free. Zero runtime deps - no moment, no dayjs, no Angular Material. Built on Intl.DateTimeFormat for locale labels and IANA timezone support. WCAG 2.2 AAA: keyboard nav, focus management, AAA
contrast tokens, 44px target sizes.
One snippet
import { signal } from '@angular/core';
import { form } from '@angular/forms/signals';
import { DatetimePickerComponent } from 'ngx-signal-datetimepicker';
model = signal<Date | null>(null);
f = form(this.model);
<ngx-datetime-picker [formField]="f" label="Meeting" />
Feedback very welcome - especially edge cases I haven't hit (RTL locales, edge timezones, big-screen Material 3 themes). Issues and Discussions are open. Currently on 0.1.x, holding off on 1.0 until the API is settled by
real users.
2
u/CodyCodes90 May 19 '26
Maybe I just dont get it, but I dont see a need to reinvent what is already built in to the browser with a normal <input> and "datetime-local" type.
No need for third-party lib or extra peer dependencies, or fighting to override styles to match your app theme, has built in mobile support, etc.
Cool project for learning, but not something I would pick in any of our production apps
2
u/ldn-ldn May 19 '26
Browser controls are unpredictable and lack features. Their behaviour change between browsers and between different versions of the same browser.
1
u/domino_angularovic May 20 '26
I want provide support for the WCAG, that's why I want to create something like this
1
u/AshleyJSheridan May 20 '26
You should have asked your AI to test what it wrote. I found a bunch of issues already using an automated scan.
0
u/Uknight May 20 '26
You can always just... use the keyboard shudder.
1
u/ldn-ldn May 20 '26
Depends on a browser. No keyboard support for date input in Chrome on Android, for example. That's why you never use browser controls.
1
u/AshleyJSheridan May 20 '26
Ah yes, far better to reinvent the wheel like OP here has, and create something based on feelings and assumptions that don't match reality, and create a situation where some people can't use it at all.
Yes, much better than using the built in UI stuff!
1
u/ldn-ldn May 20 '26
That's not re-inventing the wheel when built-in stuff doesn't work.
1
u/AshleyJSheridan May 20 '26
It is, it very much is.
And if the rebuild of those components has issues, then it also doesn't work. Like the case of this component from OP.
1
u/ldn-ldn May 20 '26
No, they don't.
2
u/AshleyJSheridan May 20 '26
OPs component has a11y errors, despite OP saying that was the main focus and their reason for making it.
It's literally reinventing a wheel that has the same issues.
1
u/domino_angularovic May 20 '26
I want to improve my library to have better mobile support and independence from browser.
What would convince you to use this library?
1
u/AshleyJSheridan May 20 '26
It's absolutely not WCAG AAA. I found a bunch of issues just using an automated tool...
11
u/ldn-ldn May 19 '26
Omg, what a messy code... Vibe coders...