Identifying a Date value in an object type

If I iterate through an object type, I can look at each key:value and do this:

if (value.extends(type.number) { // Do some stuff 
}
if (value.extends('boolean') { // Do some different stuff 
}

if (value.extends(type.number) { // Do some stuff 
}
if (value.extends('boolean') { // Do some different stuff 
}

How am I meant to check if a value is a Date? I have something like this:

const schema=type(
    {
        id: 'number',
        last_updated: 'Date'
    }
)

const schema=type(
    {
        id: 'number',
        last_updated: 'Date'
    }
)

If I iterate through the keys of a type like this looking for a Date type, I can't match it in the way I can match Boolean or number.

if (value.extends('Date')) { // some stuff 
}
if (value.extends(type('Date'))) { // some stuff 
}

if (value.extends('Date')) { // some stuff 
}
if (value.extends(type('Date'))) { // some stuff 
}

Neither of these work.

24 Replies

TizzySaurus•3mo ago

type("Date").allows(value) should work I think Keep in mind it has to be a literal Date object, and not a string representation of a date

Stuart BOP•3mo ago

Sorry, misunderstanding. I'm not trying to identify a date ibject, I'm trying to identify a type that allows a date object.

TizzySaurus•3mo ago

I guess you can inspect the schema :Shrug: value.json.prototype === "Date" iirc You can do console.log(type("Date").json) to see how it's represented

Stuart BOP•3mo ago

Seems like the problem wasn't what I thought it was. I tried value.json and I still have an issue. I'm iterating through a type (validator) using

 validator.keyof().internal.distribute(
        (key) => {
    //stuff
}

 validator.keyof().internal.distribute(
        (key) => {
    //stuff
}

And using

const value: Type = validator.get(key as never);

const value: Type = validator.get(key as never);

to get the value. This works for number, boolean, string. But when I try it with a Date, value.json returns

{ proto: '$ark.fn19' }

{ proto: '$ark.fn19' }

No sign of 'Date' anywhere. Maybe I'll have to try rewriting using .map(). (I tried before, but Typescript was giving me all sorts of problems I couldn't work out, so I stuck with the old .internal.distribute)

ssalbdivad•3mo ago

{ proto: '$ark.fn19' } makes sense because it's the serialized representation of instanceof Date basically But I do see there are some issues specifically with .getting a Date property.

Dimava•3mo ago

Would it make sense to alias well-knowns (like Date) to $ark.Date or $ark.wellKnown.Date or $ark.instanceofDate?

ssalbdivad•3mo ago

I mean those serialized JSON representations aren't really supposed to be parts of the code people are interacting with generally, but I do think that most builtins will actually serialize as their own name by default. I still have to look into this case

ssalbdivad•3mo ago

This is how the representation should look for Date. @Stuart B This was just a bug with how proto nodes were being parsed and how that interacted with .get. Your original intuitions about how it should worko were right and it will be fixed in the next release

ssalbdivad•3mo ago

Maybe more relatably here's the new test case in arktype:

Stuart BOP•3mo ago

Thanks,good to know. I've just about got it working with the map() api now, where it seems to work as expected.

ssalbdivad•3mo ago

Yeah was a convergence of a couple things, that parse case not being handled correctly + the node didn't really need to be reparsed there by get so I'm not surprised another approach works. .map should definitely be better in general anyways if that ever fits your use case Just a higher level API that should let you do more with less whereas getting keys and distributing is a lot more granular

Dimava•3mo ago

What's .map again 🤔 Should I PR a baseline JSDoc?

ssalbdivad•3mo ago

I haven't documented it yet it's very new It's basically like a mapped type in TS in chained form I wanted to add it because @Stuart B and @PIat were doing so much internal mapping that was a pain without it

Dimava•3mo ago

So convertPropertyTypes Okay

ssalbdivad•3mo ago

There's definitely some important nuances One is that it's like flatMorph in that you can map one to many or none (filter) entries

Dimava•3mo ago

So should I PR JSDoc?

ssalbdivad•3mo ago

You mean write the JSDoc for map? Maybe if you can do a good thorough job based on the tests I'm still a bit worried about the API because TS has some super weird rules around inferring the return types that @Andarist warned me about, but I think I've worked around those with NoInfer where needed 🙏 Also I remember Errata (I guess he left the Discord) had suggested publishing the unit tests to the docs site as a fallback which I think could be really helpful as a stopgap if you're interseted in helping with that I started splitting the tests up more so it would be easier to find them by category Man it kind of blows my mind people like that join the Discord, send a million messages with a bunch of opinionated suggestions about how I should change ArkType either because it's wrong or to accomodate their use case, then just bail lol

Stuart BOP•3mo ago

I'm feeling guilty about causing you extra work now. But it is very much appreciated.

ssalbdivad•3mo ago

Don't feel guilty you and @PIat are very positive in most of your feedback which I appreciate a lot. It wasn't a lot of extra work, and it just made more sense for me to build a better API around it so that people wanting to do this kind of stuff had a solution that didn't require .internal and a bunch of hacking where I'd spend more time answering questions than I would have just building a real API for it 😛

Dimava•3mo ago

I think you should start to slowly test your stuff with AIs, e.g. Cursor If AI can't answer 80% of questions that means your docs are not good enough Considering AI can easily read all the unit tests, you should be able to beat data into its brains relatively easily as long as you explain properly (It will suggest stupid stuff that doesn't exist anyways 😜 )

PIat•3mo ago

How could we not be positive ☺️ You turned form validation from being the ugliest part of our codebase into being the most cherished That's actually a good idea, tests are named and described, so they give explain the context about every bit of code

ssalbdivad•3mo ago

I mean TBH I don't really need help knowing what needs to be documented haha, I just need help documenting it which unfortunately AI still has a hard time with I've given meta prompts to look at all the unit tests and summarize major features but it's not good enough to be worth using even as a baseline Just providing the tests themselves would at least be a stop-gap I know is accurate

Dimava•3mo ago

So Do AT functions have JSDoc at all? (apparently I didn't check it for quite a while lol) If not, should I make short JSDocs on basic functions so I don't Cuz I want to have those so I don't forget what the function does again and don't want to wait until you start doing it if you haven't started yer

ssalbdivad•3mo ago

Yeah go for it I haven't worked on it at all my plan has been to finish the docs site first

Gaming

Programming

Identifying a Date value in an object type