Everyone's talking about ArkType
HTML-код
- Опубликовано: 16 апр 2023
- ArkType is a brand-new competitor to Zod, with an extremely innovative syntax and some extraordinary TypeScript magic.
Docs: arktype.io/
GitHub: github.com/arktypeio/arktype
Become a TypeScript Wizard with my free beginners TypeScript Course:
www.totaltypescript.com/tutor...
Follow Matt on Twitter
/ mattpocockuk
Join the Discord:
mattpocock.com/discord
![mgk - Sun to Me (Zach Bryan Cover) [Live from Cheshire Cottage]](http://i.ytimg.com/vi/_ZnbTEs4O6U/mqdefault.jpg)
Hey everyone! Thanks for all of the feedback, it's really helpful 😊
I know the documentation is really lacking at the moment (working on fixing it for the next release ASAP!). In the meantime, while certainly not a substitute, I'd be happy to answer any questions you have here.
Thanks again to Matt, not just for making this video but in general- it's been amazing to have so much more consumable high-quality content on the TS ecosystem than there was in years past 💖
Nifty work man!👏🏻 Always great to see fresh takes on recurring problems 😎
nice work man, the things people do with typescript blows my mind sometimes
Awesome work!
Documentation is still the main issue why I would prefer Zod.
It’s really impressive that this is possible, but I’d still prefer zod.
Being able to see all your options with autocomplete makes life so much easier. ArkType has its own type of language you’d have to learn and just know.
Ark might be a good choice for runtime typing. But very niche scenario.
@@reapi_com that's what Zod does too
I think part of the context that might be missing is that it's an expanded version of TypeScript syntax, so unions, intersections, arrays, literals etc. all work and are inferred exactly the way they are in TS natively, and all keywords have built-in autocomplete, which helps a lot with discoverability!
I will be adding some options for chaining in the next release for complex scenarios with multiple objects, but goal of the library is to build off of TypeScript's own syntax, supplementing it with runtime constraints like "0
couldn't the last part of your statement, "... its own language...that you have to learn and know", also be said about Zod?
A big thank you for keeping us updated on the typescript eco-system!!! Great work Matt
For the use-case in the thumbnail (marshalled object version field), I found replacing it with a versioned URL to a JSON Schema under the standard $schema key to be great for self-documentation and autocompletion.
I like the novelty of this but this would be a hell to maintain because its essentially a language of its own.
It's almost entirely just based on TypeScript's own syntax. Only runtime specific features like bounds, divisibility, etc. have a custom syntax that should be intuitive based on normal runtime checks in JS/TS (the range in the example should have been "0
The fact that the bound in the video was incorrect is a perfect example of how this could go wrong. What's the advantage of this syntax..?
@@davidblass4552 But why? What is wrong with libraries like zod?
z.number().min(0).max(200) is so intuitive to understand compared to a simple string which will have runtime implications. Personally it would drive me nuts.
@@wlockuz4467 Well I think what is familiar to people is always going to feel more intuitive, so that is certainly a barrier we will have to overcome.
That said, I don't think most devs familiar with any language (or even non-developers) would be confused by what "0
I'm glad I'm not the only one who found the docs to be a little...wanting. That said, it's still a really promising project!
Amazing! Thanks!
This is literally the first I ever hear about ArkType :) Speaking about Zod competitors, have you tried typebox? If so what did you think of it? Fastify recommends it so I use it in my backends, but like Zod's syntax more.
I think TypeBox is great! Really well-designed and definitely an underrated validator in my opinion.
looks good. Thanks for sharing
The mathematician in me screams when he sees "number>00 && 0 0 && number
The allowed version would be "0
Hey Matt, love your TS videos, one request please make some videos on Custom AST Compiler for Typescript. WE don't have much video resources around that
I wonder if/how they'll do transformations. zod handles those amazingly, tho I haven't tried async transformations yet (simply didn't need them).
This is pretty wild. doing type-level string interpolations is not that easy, I'd personally stay away from anything more than maybe creating dynamic keys based on existing ones. I guess just parsing out type number from "number>0
Type level string interpolation is arguably the only thing that is intuitive to do in typescript.
Oh thank god, it has been 6 minutes and 32 seconds since a new JS lib has been released. I was really starting to get anxious.
I'm not a fan 'number>0
Yeah this should be a syntax error actually, double bounds are meant to be defined as "0
I'm not sure about the value of validations using a custom string syntax when Zod already has `.refine` which allows you to narrow down the domain of your type with plain JS/TS.
Similar functionality exists in ArkType:
narrow("string", (s) => s.startsWith("foo"))
In our upcoming release it will be:
type("string").filter(s => s.startsWith("foo"))
Meh. I find chaining methods to be cleaner
That's true and easy to read
Agreed, much better
40kb of js
I think part of the context that might be missing is that it's an expanded version of TypeScript syntax, so unions, intersections, arrays, literals etc. all work and are inferred exactly the way they are in TS natively.
I will be adding some options for chaining in the next release for complex scenarios with multiple objects, but goal of the library is to build off of TypeScript's own syntax, supplementing it with runtime constraints like "0
Hard agree
What are some use cases for this?
Impressive library, but I much prefer having zod's structured data than complex strings you'd have to parse to get the raw data back of out.
The data you pass is the same, and the "number>0
typecript wizard on top of the game again
Looks good, but going through a rudimentary browsing of the docs I don't see the ability to create my own custom failed validation messages, which, depending on the use case can be a blocker.
Ha, it looks really like Laravel validation strings:
'age': 'required|min:0|max:99'
I like that TS stuff :D
Please continue showing us new stuff
sheeesh that is so cool
Started watching since HOTScript
Welcome!
I remember those days (four days ago)
Do a second video showing how Arktype automatically does discriminated unions(and recursively discriminates) and how you compose types with scope() and you might be sold on it
I'm surprised it can lint your strings, but not give syntax highlighting.
It's not a plugin, it's just TypeScript's type system giving that feedback.
Unfortunately, as far as I'm aware TypeScript does not have an ability to add syntax highlighting based on generic types :P
Out of curiousity, since you've already answered it for someone that's familiar with Zod. Would you recommend Zod or ArkType for someone that's used neither so far. (given one puts faith in the documentation of ArkType being improved)
Zod!
Have you head of Deepkit? they're doing some real typescript magic to achieve this kind of thing for their ORM and validation
0:55 craaayzyyy 🤣
does this mean all types can now be defined as JSON?
One of the primary benefits of ArkType's syntax is its serializability! It could eventually even be used across languages.
That looks rather nice... if nothing else, you've made me think "ooooh.... so what's Zod?"
That's friken cooooool. Can arktype accept a type like HexChar to constrain strings too? Or just pass a type? Since this is just a function, these 'types' by dynamically generated as well which blows my mind up xD
```ts
type HexChar = 'a' | 'b' | 'c' |... | 'f' | '0' | '1' | ... | '9';
const UserTag = type({
char: HexChar,
name: 'string'
});
```
It can constrain strings by regex, which is fairly nuts.
@davidblass4552 Putting the question mark in the key to indicate optionality 🤌 Is there a way to represent "question-mark-less" optionality? e.g. { name: string | undefined }? Zod can't do this either yet.
Yes built-in TypeScript syntax just works, you can define "string|undefined"
Check out superstruct
One thing - would be nice to introduce Zod in this video. It is referenced couple of times and I almost bounced of this video because I have no idea what Zod is.
Wazzup
Make a video about Typia, it's this extremely based and way better than Zod tool that makes the types sound.
Docs are pretty rough! And I'm not a huge fan of needing a TS plugin for my library.
I've just recently learned about Zod and now there's already a replacement?
I still prefer zod due to better autocomplete, and I think better runtime perf too (this all has to be parsed and evaluated at some point!)
@@davidblass4552 oh dang, thanks for pointing that out. I should've looked up their docs before throwing my assumptions out there.
(But I do hope we can get a similar API to zod at some point 😅)
What killed the idea for me is that is uses strings. They are not composable unlike Zod, where you keep the type around and can extend it further. There are cases where I pass partial Zod types as arguments and whatever function can extend it further if need be.
We will be supporting chaining in our next release! The goal is to have any definition that can be defined as a 1:1 with TypeScript done that way, but stuff like this is definitely really nice with chaining syntax IMO:
type({
a: "string",
b: "number"
}).filter(data => data.a === "foo").morph(data => ({a: data.b, b: data.a}))
This would automatically be inferred as {a: number, b: string} when validated
1:18, I would have put the ? syntax on "string" instead of the property name...
Agree. It would be more intuitive.
Yeah, I'm in the same boat. However, I guess this way is just closer to the typescript syntax.
I've thought so much about the specific trade offs here. I might allow that as an alternate syntax, but in general the default is to be as close to 1:1 with TypeScript as possible, and logically the mode should be that the optionality belongs to the key, not to the value.
That said, having to quote your keys 😭
@@davidblass4552 I mean, this syntax isn't very typescript-y to begin with. You are providing properties and the possible values of them. A ? would mean this property can be "undefined", so it still is a reference to the value. To me the downside besides the quoting is the consistency. The left is the property, the right is the rules for what that property's value can be, except for this particular rule.
@@Troncoso01
TypeScript:
type user = {
age?: number
}
ArkType:
const user = type({
"age?": "number"
})
It is definitely optimal from a TS-syntax 1:1 perspective, which is a big part of the goal of the library. Arrays, unions, intersections literals etc. work the same way
1:36
Matt *writing code*
IDE: problems?
xD
honestly this seems easier than zod
Yeah I think this is going to be a lot of folks' reactions. I personally prefer Zod's syntax - and obviously it's a more mature library. But having a worthy competitor is always great.
There are a few downsides currently.. Stuff like `type('[string, string, number][]')` currently would not work.
First zod allow your to defined property level error message.
I will keep zod thanks
Hey wizard! Mind to make your wizardry in this video - v=B7ygRIQcQPE , please? I loved it but somehow I missed some point and everything went weird after some part 😅
from a Typescript perspective is impressive, but the syntax is actually terrible. Zod is much more readable IMO.
and I'm still stuck with Joi
Intellisense will become old news if copilot-like tools become good enough.
Nope. Because Copilot would not be able to keep up with all the documentation changes of all the libraries. And parsing them all, send them over the network, to get predictions about your code back would be crazy.
@@RedOchsenbein There's no reason it couldn't keep up with documentation changes with the right architecture. I was a bit sensationalist as it would most likely augment intellisense, but making architecture decisions contingent on intellisense capabilities will become unnecessary.
I don't see the advantage or appeal of encoding all of this information in a string, to be honest. I would really rather have standard language features like validation functions that editors and other programmers will natively understand.
Year 2023. People rediscover reflection types once again...
Great, another proprietary syntax for yet another library that can already be done in a more widely adopted fluent API.
It's not proprietary and it' just reuses TypeScript's own syntax for things like arrays, unions, intersections, literals, etc.
Stuff like "0
ArkType is based on eval afaik. This is a real bummer since it will be a no-go for many security related projects. (#CSP)
It's not on main, but on the perf branch we are implementing a strategy that uses the Function constructor to optimize perf (this allows it to validate 400x faster than Zod).
We'll add an option to precompile validators altogether though to avoid parsing at runtime entirely, so shouldn't be a blocker.
@@davidblass4552 wow cool this sounds awesome!
Zip this video up a bit and make it a RUclipsShort
That looks good, but typos will destroy this approach, so no thank you, by the way, why does everyone prefer ZOD over AJV?
That's why there's autocomplete and syntax validation, so it's >= the level of type-safety you get natively writing definitions in your IDE!
bro, that's black magic
It's cool but it'll never replace zod
Another day, another new library. No thanks 😂
This is one of those things that makes me pose the question "What's wrong with vanilla javascript?". Why import an obscure library that makes people have to go read docs vs just looking at and understanding your code? This is the type of stuff that causes prod errors. Neat but not practical.
I get where you're coming from here. I really do. But having a 100 if statements check that your types are correct isn't practical, and it is more difficult to understand than this library. I also went the route of just doing it myself, and it bit me in my ass quite thoroughly. Having this library provides a predictable list of problems that your input created. This list of problems is essential when using an API. Too often have I had to use an API that just said "Your input is wrong, try again", and if this takes a step towards ending that, I'll gladly take it.
"just looking at and understanding your code" It's not feasible if your codebase is hundreds of thousands of lines of code and you have more than 10 people working on it.
Lol this mid level developer is going through one of the phases before our very eyes.
@avi7278 yeah... that's it. You got me...
Why use typescript for that matter. Why use React. I can just do it in vanilla js. Why even use js, i can just use php. But why use php if I can use a rock and a stick?
But why?... 😂
Typescript ecosystem loves to over complicate things and build gimmicky things. Though it looks like a fun library, why would u want to include these checks inside the type strings? Work in Java for a while, u will realise all these things r not needed and ur programming will improve. Most of the typescript gimmick features can be easily handled using interfaces and abstract classes.
Java is a severely outdated language. You are behind the curve bro.
@@Cassp0nk lol java is not outdated. If u want a good senior backend engineering job at majority of big tech companies, u need java. Majority of bit tech companies, investment banks and all use java as their core backend language, with python, go, nodejs etc for some services. Majority of tech companies including google, amazon use java as their core backend language, facebook uses Hack/php, microsoft uses C#.
P.S: I have worked in JS, Python, Java, Ruby, Scala at my jobs over the years.
so is zod officially dead ?
Feels like someone really enjoys Rust macros, but is forced to write typescript.
zod is nice till u need a custom errors loool
Gonna have to do better than "it's different" in relation to zod. I doubt I'll ever go away from zod. Let's stop somewhere. How about that?
bruh , zod replaced 😭😭😽😽
Nah, dont think that string validation is a good thing
gives the term stringly typed a whole new meaning 🥲
Stringly typoed*
"email?": is increadably ugly
Ew
No, no no no, no.
zod is much better
Does it run on runtime? No! Useless...
Yes, it does.