vaadin / hilla

Build better business applications, faster. No more juggling REST endpoints or deciphering GraphQL queries. Hilla seamlessly connects Spring Boot and React to accelerate application development.
https://hilla.dev
Apache License 2.0
922 stars 57 forks source link

DTO TS Generation should convert Java Date/LocalDate to JS Date #927

Open gitgdako opened 1 year ago

gitgdako commented 1 year ago

Is your feature request related to a problem? Please describe. I'm always frustrated when I have to call new Date(string) on any DTO property that could be a JS Date but is a string

Describe the solution you'd like Java Date Objects get converted to JS Date Object instead of strings

Describe alternatives you've considered copy pasta as described above

Reproducer Any DTO that is converted into TS with the code generator with a java.util.Date or LocalDate property

Additional context Doc reference: https://hilla.dev/docs/react/reference/type-conversion#date-time-types I have discussed the issue via expert chat with Markus Linsford and he asked me to mention the following: "at least with Flow stuff when executing Javascript calls directly from Java, Date values aren't directly supported, but are converted to Strings" Furthermore I have a minimal reproducer in our private GitHub that was shared with Tatu

TatuLund commented 1 year ago

Regarding dates, I think there was some slight difference in our DatePicker and UI5 DatePicker behavior. The both have value as String. But Our DatePicker works so, that the presentation value and internal value has conversion in the component. I.e. the actual value is always having the same formatting. And our Java <-> JSON conversion assumes that standard format. I have a faint recollection that UI5 DatePicker's value is according to format you have set the pattern. Which I think is a bit odd implementation. So if you use localized date pattern there, you need to e.g. wrap the DatePicker and convert the value to standard. Then it should work.

gitgdako commented 1 year ago

I get that having a standardized date as string in a specific format for the datepicker is a nice thing but so far we have used Date values in a lot of different cases and only one of them was an actual datepicker input. If the datepicker can only accept string I would wrap that to take a Date and format that Date in a specific way, but the other way round for any other usage I would like to not have to convert to a JS Date every time I want to use any of its properties

platosha commented 1 year ago

This is a known limitation, but still thanks for the feature request. Enabling this by default would be a breaking change, but we could probably add an opt-in support for this in some minor release too.

Please upvote this issue if you would like to have it.

gitgdako commented 1 year ago

JS Dates apparently have the same downsides that java.util.Date has and its same issues. ECMA wants to implement Temporals in JS (https://tc39.es/proposal-temporal/docs/), using these would be the prefered mapping