Add datetime field #552
Add datetime field #552
Conversation
emilienbidet
requested review from
simonswiss,
BarnabyBishop,
emmatown and
JedWatson
as code owners
🦋 Changeset detectedLatest commit: 540088e The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Hey @emilienbidet! Thanks for the PR. It's late Friday evening here in Australia so we probably won't land this before early next week, but at a glance it looks good. Will get you a proper review soon! |
|
Hi @JedWatson ! Thank you for your answer! Okay, have a nice weekend then! FYI : I didn't handle timezone, I went straight to basic. Thank you very much everyone, |
|
I'm wondering... Why for keystatic date field we don't use the Another implementation of this datetime field would be to just to update the date field to make it use the DateField from the design-system and add the granularity props as a field customisation properties like this : datetime: fields.date({
label: 'Date and time',
description: 'The date and time of the event',
granularity: 'day' | 'hour' | 'minute' | 'second',
validation: {
isRequired: true,
min: '2023-08-15T00:00Z',
max: '2023-08-20T00:00Z',
},
}),I prefer this approach because it match to the design-system and let the dev choose what type of date he wants. |
|
Hey @emilienbidet! We took a look at this, and I also had a chat with @jossmac about adding Time support to the We'd like to expand on the design system component so it can handle selecting times as well, but it's not going to happen quickly, and it should be fine to update the UI for this field in the future when the design system component is ready; the native type is less consistent but will get things unblocked and it wouldn't be a breaking change to switch them out. In terms of having one field or two, we're inclined to go with two, because we've found it easier to manage each field type having a distinct data type that it serialises to; e.g we're planning to improve on slugs in the near future and one of the things that we want is to be able to encode date / datetime field values into them to make filesystem sorting easier. In that case, you'd handle the value differently, and having distinct field types makes that easier than one field that has a variable type. So we're happy to go with this implementation for now! |
There was a problem hiding this comment.
Great PR, thanks @emilienbidet!
Very happy to have you contributing to Keystatic ❤️
Hello Thinkmill and keystatic team 👋🏻
Following #444
I need the datetime field for my personal project so I just did it.
Thank you open source, this is my first real contribution to keystatic, so glad to work on this project.
Added dateTime Field and Documentation
Changes Made
datetimeto handle DateTime input using the<input type="datetime-local">form field.DatetimeFieldInputcomponent for capturing Datetime input.validateDateTimefunction to handle DateTime validation.DatetimeFieldDemoto showcase the usage of thedatetimefield.datetimefield, its usage, and type signature.Please review the changes made and let me know if any further adjustments are needed.