Add date and time support client-side#28
Add date and time support client-side#28DanielOrtel wants to merge 1 commit intofrancisconeves97:masterfrom
Conversation
| } | ||
|
|
||
| export interface DateField extends BaseField { | ||
| type: 'DATE' |
There was a problem hiding this comment.
DATE and TIME fields act exactly like SHORT_ANSWER and LONG_ANSWER from what I could see, since they're basically just strings, so it makes more sense to group them together
There was a problem hiding this comment.
Are their format the same? Would it make sense to add some validation regarding the date format? I will have to take a deeper look into how google forms handles these type of inputs
DanielOrtel
force-pushed
the
date-time-support
branch
from
24d7876 to
fc3f12e
Compare
|
Hey, @francisconeves97, sorry for the ping, but was wondering if this is something that you could take a quick look at. I'm sort of on a deadline, and I'd be nice if this was available in the package |
|
Hey @DanielOrtel! I am sorry for taking so long to look into this, past couple of weeks have been very busy for me :/ I will try to check it asap as soon as I can. I am sorry for the impact on your project |
| case 'DATE': | ||
| questionInput = <DateInput id={id} /> | ||
| break | ||
| case 'TIMe': |
| } | ||
|
|
||
| export interface DateField extends BaseField { | ||
| type: 'DATE' |
There was a problem hiding this comment.
Are their format the same? Would it make sense to add some validation regarding the date format? I will have to take a deeper look into how google forms handles these type of inputs
From what I could test, the DATE and TIME fields are exactly the same as the SHORT_ANSWER input in every way. Google does not validate the format on the backend, it merely presents a date-picker/time-picker component on the client side when it sees the Date/Time formats, but programatically, it will accept any string, including |
|
also, sorry about not being up-to-date on this, we've opted to drop the date field, and just use a text field for that, since we had to release a week ago, so this was no longer that high priority. But I'll try to address the concerns you raised shortly. It would still be useful to have |
2 participants
Since these two fields are basically represented as strings and act exactly like short and long answer, this is a pretty safe and trivial addition.
Tests are passing, and tested manually to see the whole submit flow, everything works as expected.
Test form, in case you need it