Mikita Kamkou

It would be nice to have. I'm thinking about writing my generator, but if it's implemented in your library it would be just awesome!

The same issue for me, any updates on this one? I'm not sure how the select component is implemented, but maybe it needed to be refactored with the listbox component...

Also, it looks like generic doesn't solve the issue because the `@internationalized/date` package uses ESM private fields in the classes it exposes, and vue, when unwraps ref, can't unwrap private...

Yeah, I personally ended up using different calendar library, while radix-vue calendar is good, I don't want to use `@internationalized/date` that relies on classes because if they potentially remove polyfil...

Yeah, you're disabling reactivity. Still, for most of the cases, it wouldn't be the problem as `v-model` even now emits new instance of the `CalendarDate` each time it changes, but...

In any way, I guess it makes sense to add a generic to the Calendar component. It will make types clearer and stricter. For example, if we provide `defaultValue` as...

I'm not sure it adds any uncertainty to the component. To be honest, I don't quite understand how your points are related to the types I proposed. When you add...

Yeah, makes sense. In this case `CalendarDate` will be emitted while user expect `CalendarDateTime`

Yeah, also, the example I provided is far from ideal because it's not how you use the calendar if you want date time to be honest. Because if you want...

Also, could you explain what problems with `ZonedDateTime` and `CalendarDateTime` you are talking about? Cause I've scratched only the surface of the code, I'm not quite sure. For me, everything...