How to incorporate existing type?
I have a type imported from a third-party API and I'd like to build it in into my ark type:
51 Replies
I understand that validation will not be made in runtime
but still, is there a nice way to add a stub for external types?
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
sure, it can only be an assertion
isn't there a way to do it now?
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
So you just use a narrow function with a type guard or a cast
I think he was asking for how to use the type not how to implement the validator but yeah something similar to that could work
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
Well, that's casting for you
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
Just don't cast in TS KEKW good luck
If you're using ArkType you're casting like a thousand times under the hood anyways you're just trusting me and I'm not that trustworthy
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
Probably impossible? It's literally impossible to write a generic function that returns a mapped or conditional type using its parameter without casting
So given you can't write a function to replace a key in an object without casting, yeah I'd say ArkType is pretty doomed
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
Lmao you don't think I know
DO YOU EVEN KNOW WHO I AM BOY
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
You mean tha's how it will work in the future
And 1.1 is what you folks usually call
beta
branch, right?He just made that up but yeah that is what he means
It's actually like this:
I see, cool
I had to double cast in my code 🙂
First time here:
And second time here:
Because it seems like
Infer
did more with the original type than just "using" itI should say that
PollyClientConfig
definition is pretty... complex
It's something like:Not sure if
pollyConfig as PollyClientConfig
is enough to make TS happy, i.e. to not make it trigger that instantiation deep error, so I added pollyConfig as unknown as PollyClientConfig
Huh I mean that does seem crazy. Have you tried using interfaces for this? They tend to be more performant for combining many objects
It's not my type I cannot change it
Yikes. Well this would be another case that would benefit significantly from the inferface boundary strategy I mentioned otherwise AT has to look through this type for morphs
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
I don't consider this to be a major API. The vast majority of the time the type will be inferred from the definition.
The second option is impossible because that parameter would be for the definition.
Maybe the first is fine, I think I probably considered it and thought it read more naturally if it was always
type
that actually instantiated the typeU need double generic that's why
Yeah the second is doomed I guess
The first rather
Also maybe type.for sounds better if it's on type
But again its double call
Unless you want
type.declare<Foo>()({def: "string"})
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
declare<Foo>()
creates a declaration for Foo
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
If it's scope.for<S>().foo(fooDef)
...
... Okay I don't like it
The declaration has a
.type
function attached that lets you instantiate it
Idk it seems reasonable and I trust my past self to have thought through the options carefully in a case like this
.scope
will be on the same declare
return typeYou need double generic (a provided type and a infered type)
Yeah the way it is is best. I think leveraging intuitions about "declaring" a type and later having to instantiate it is definitely clearer than
for
which is a reserved keyword and could also mean lots of other things
Plus it's natural to leverage a TS keyword declare
like this to parallel our use of type
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
Xactly
You either provide all our infer all
There is a proposal for this I said it should be
<required, optional?>(required: required, optional: optional): unknown
Basically if you pass any parameters, all the required parameters would have to be passed
Just like now
But optional parameters can not be passed and would be inferredI'd say it should be
f<T, infer S>
That makes it look like you can never pass it
Which would be fine as a feature but it's misleading based on the proposal
Or
f<T, S = infer>
Yeah that seems reasonable why didn't I like that as much
I'm sure I explained it if you want to go find the issue I'm too tired
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
Yeah seems good makes me wonder why I didn't like it I know it was one of the issues suggested on the thread
Or maybe I liked it relatively but I had some issue with it
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View