Default number
Hello!
Setting this brings the expected result, when ran through
inferAmbient:
But adding a default value returns a function signature:
How can I get the number type in the editor when providing a default value?86 Replies
It's not clear to me what exactly you're after here, but maybe
t["infer"] or t["tOut"] is what you're after?
Where t in this case is your queryTypeYeah you probably want
t.infer for the output or t.inferIn for the input type (would allow undefined). tOut is more internal as it contains constraint brandsThank you!!!
inferIn is exactly what I needed
I am using Arktype as my form, params and query schema, and am inferring the types from the schema for type-safe endpointsIf you want to create it from typed input, there's also a
from method that accepts it
Like queryType.from({})
Would result in {page: 1}And if I do
the result will be {page: 20}?
Yeah it should
So for form parsing it's a better variant than doing
?
If you're ever passing in known data like that, I'd use
from so you get type safety
The default method is for accepting unknownActually it was
infer, for the output as you said 😅
But other than that, they both produce the same result on runtime?Yes, under the hood it just calls
assert which is also identical to the base method other than that if there are errors, it will throw instead of returning an errors object
But it looks like in a case like that where you're passing an object literal there should never be errorsThere will be errors if someone passes a wrong type
So in your case
queryType({page: 20}) is just an exam,pleIf they send
But doesn't TS enforce that anyways?
or would they not really be passing an object literal
It seems like if they passed something invalid you would want to throw
They're always passing an object literal (Remix converts formData and query params into an object), but they might be passing wrong keys or types if they'll call it through some other client than the website
.from is just like .assert at runtime, just it accepts typed input
The only difference between the base method and .assert is whether you want to get an ArkErrors return or throw directly, which generally depends on if you can handle an error or you just want to crash if the data is invalid
(still crash with the same good error message)In my case I return the errors and show them in a toast message, or if it's a form, then under the wrong fields (that's why I made the simple i18n POC 😁 )
Use the root method then, but since you're not the one passing the data,
.from would be irrelevant anywaysI understand this 100% now
Good, you can right some docs for me 😛
Thank you so much, I won't be guessing anymore
I would be down if I were more helpful than a nuisance 👀
I really like the Fumadocs bar TOC 😆
To be honest, I really love the Arktype website. You enforced modern design language with great illustrations, fonts and colors and the responsiveness is great
You saw the issue I just created I assume?
Yes
I would want it to look very similar to how it does now, I just don't like dealing with astro components
It's so good
Stuff like this too
Makes the homepage feel alive
It's very impressive you know 👀
Yeah haha I'm definitely proud of the code blocks I spent a while on those
Now to create all the content that uses them 😛
All the customizations were with CSS + shiki really so it should be translating to whatever is in next
It's a lot of the same underlying tooling
I'll probably set it as my browser homepage once it's done 😁
Just gotta change some underlying css variable names etc.
Hopefully you don't need the docs so often that that becomes necessary 😛
I worked with Astro some 1.5 years ago because back then I really liked the idea of not being locked into a front-end framework, since I was experimenting with the frameworks to see what's most comfortable to me. When it came to dynamic and interactive content, it wasn't very great, since it's not the framework's focus and from what I remember there were some typing issues on the components
Yeah the TS editor experience kinda sucks
They publish raw
.ts files to their node_modules which always gives me errors in my IDE
And it's been really hard to reliably get types/errors without a bunch of nonsense in the astro components + mdx
It kinda seems like on the one hand it's not locking you in, but on the other it's locking you in to astro 😛Yeah, you have to set it up very specifically
Right and I've already spent more time on that stuff than I want
I just want React
That was my conclusion too
And I guess to be able to reference that stuff directly in MDX, but I don't need anything else
You wouldn't believe the hacks I ended up using to get all the highlighting to work between astro/starlight and shiki lol
GitHub
arktype/ark/docs/src/components/shiki.config.js at main · arktypeio...
TypeScript's 1:1 validator, optimized from editor to runtime - arktypeio/arktype
Yeah that's part of it, but there's also https://github.com/arktypeio/arktype/blob/main/ark/docs/src/components/Code.astro and https://github.com/arktypeio/arktype/blob/main/ark/docs/src/components/addCopyButtonListeners.js ☠️
Wait, all this to make the copy button?
Because you can't add React components directly?
Yeah hooking into whatever they were doing was ridiculously complicated
Crazy...
Basically if I had just been able to use the default config options it would have been great
Well you had to use default web js
But because what I needed wasn't supported there, customizing it was awful
Yeah...
Surprising
Strange thing, Shiki
You had to add button html as a string literal ;-;
Then add those hooks ;-;
WTF is this
A bear! Duck!
Well yeah those are chill
But I just don't understand how I'm supposed to write this syntax so the parser doesn't blow up in mdx
Not sure where you have an
! thereThere is no
!, it's some nonsense way later in the file that shouldn't affect anything the parser is just badMaybe they expect
"type(\"string\")" instead of 'type("string")'I tried that too
Oh I figured it out it's because I renamed the file to
mdx figuring it was a superset of md but <!-- comments I guess aren't supported? So it was related to ! at leastHuh
But the syntax highlighting is really unreliable and I've seen tons of cases where the editor extension does crazy stuff when I'm typing random content like turning my words into imports from TS and adding them to the bottom of the file in broken syntax
https://discord.com/channels/830184174198718474/1274367848474742845
Yeah, it's just awful
You're just writing in notepad at that point
This is really surprising
I'll have to install
remark-mdx-html-comment thenYeah I don't see any reason it wouldn't be a superset
I write my notes in Markdown. And all the posts on our website are done in Markdown
I went with Markdown directives instead of MDX for this exact reason
Markdown is eternal, and my directive parser will work in 20 years, MDX seems to be everupdating
But of course I don't have the IDE needs, it's done with a simple markdown editor that parses the directives
I really found it simpler than to import components in the files 😁
Or like this that is happening to me now, so confusing
Another part was non-programming coworkers wouldn't understand the syntax that well and would mess up more than with directives, if they ever need to touch the markdown source
Huh????
That's so annoying
Do you need the
{ there?Yeah I guess it's how they recommend doing comments in mdx
you can use JS(X) comments instead: {/* stuff */}.
https://github.com/mdx-js/mdx/issues/1042#issuecomment-1008653291GitHub
RFC: MDX comment syntax · Issue #1042 · mdx-js/mdx
As part of #1039 comment syntax currently only supports JS comment expressions: # Hello, world! {/* I am a comment */} This syntax is nice because it feels more JSX-y than HTML comments. However, i...
I can't find any recommendations in general, just the MS website
Honestly I'm just using
Ctrl+/ to autocomment things and going with whatever it doesAnd it does that :/
So you can use root-level comments now?
This is your issue
https://github.com/prettier/prettier/issues/15163
GitHub
Multi-line comments in MDX are malformed · Issue #15163 · prettier/...
Prettier 3.0.0 Playground link --parser mdx --trailing-comma es5 Input: (whatever indentation or variation) # Hello, World! {/* This is a * multi-line comment */} Output: # Hello, World! {/* This ...
Nah it doesn't work
Or at least with nested code blocks and stfuf it can't parse it
And all the syntax highlighting breaks
Oh well
@PIat more joy with mdx formatting
I thought I was going insane and was somehow adding the extra backticks myself
That's so bad
But it seems like a Prettier issue?
I don't know who owns the mdx formatting. I'm using
prettier-plugin-astro which theoretically should own making their core syntax workWell code highlighting seems to be fine there at least 👀
Yeah I actually figured out a crazy hack to get those code blocks to work well within components. I don't think it was meant to work but it does and it's wayyyy better than what I thought I would have to do haha
https://discord.com/channels/830184174198718474/1279159531280138250/1279203600714825869
Huhhh
That's a wild syntax
But the editor experience should be muuuch better now
I don't think it's meant to be supported but basically I can force it to render and I guess it respects the MDX syntax, which means I get highlighting 🎉
I still have to be super careful with formatting because it arbitrarily fucks my shit up, but yeah when it works it's way better 😛
So you're staying with Astro?
I mean I'd still rather migrate so I have more control but I'm just happier to write a bunch of codeblocks in the meantime
Great 🥳🥳🥳🥳
I'm not going to spend the time doing that when there are lots of things only I can do. maybe someone else will want to do this and they could probably do it better 🙏
You mean to migrate to new docs? 👀
Yeah I created that issue but I won't prioritize it unless someone else takes it up realistically