Fork me on GitHub
#clojurescript
<
2021-12-08
>
zendevil.eth08:12:39

I have only used reagent and was looking at rum. In reagent we use react components like so: [:> Foobar …]. Is it possible to do that in rum. If so, how?

Ryan19:12:41

any clues for using inst? with

(js/Date.parse ("2020-02-02")) 
or similar? Just something to easily determine if the value is a date

p-himik19:12:56

Is the format always yyyy-mm-dd?

Ryan19:12:45

Let me check, its output of input[type=date]

Ryan19:12:58

It looks like unless I ask it to format it differently, it defaults to yyyy-mm-dd

p-himik20:12:26

But can a value of <input type="date"> be an invalid date?

Ryan20:12:23

I mean, its in browser, so definitely 🙂

Ryan20:12:33

and its really the value of the atom backing the date input, so even more opportunities for bugs / etc.

p-himik20:12:23

Right. Well, you can't use inst? for that because it simply checks for the class. I would parse the string, get date js/Date object from it, and then format it back into a string (e.g. by calling .toISOString and then splitting on T). After that, I would compare the two strings - if they are the same, the entered date is valid. But you need to check whether timezones can affect it.

Ryan20:12:52

Yeah of course, I think I also misused Date.parse

Ryan20:12:41

Date.parse returns string date to just seconds from epoch, but passing the date string to js/Date. "yyyy-mm-dd" creates the correct JS date object and can do what you mentioned with .toISOString

Ryan20:12:11

Thanks!

👍 1
chepprey01:12:05

There be demons here (at least there were a few years ago). Be sure to test your solution on different browsers. Chrome and Firefox had rather divergent handling of those different types on <input type="___"> . We ended up making our own custom input widgets for dates/times.

chepprey01:12:31

Internationalization was also a challenge here (and a requirement in our app); different locales have different date formats. Especially the US vs Europe with month-day vs day-month.

chepprey01:12:18

... which sometimes doesn't fail your serialization/validation code (which is worse than helpful failure), since you may inadvertently interpret March 4th as April 3rd with no helpful failure (like you might get trying to validate the "21st month of the year")

Ryan16:12:24

Thanks for the notes