Easier default with morph
Below is an example of a morph where I try to parse a duration using luxon. Unfortunately, because of the defaultablility model, I think I have to do it this way. Is there any simpler way to achieve this outcome where I don't have to provide an
ACCESS_TOKEN_TTL but if I do, I parse it as a Duration?
3 Replies
Hey assuming what you're looking for is for certain explicit values like
null to be defaulted, there are a couple issues tracking it as a feature. Would love help with an implementation, otherwise will address as soon as I can:
https://github.com/arktypeio/arktype/issues/1283
https://github.com/arktypeio/arktype/issues/1390GitHub
Allow null to be treated as not-present for optional fields · Issu...
Request a feature (Related to #1191) I wish to be able to have a type with an optional non-null field that accepts null as being equivalent to not present: import { scope } from "arktype"...
GitHub
Config for values that fallback to a default · Issue #1390 · arkt...
undefined should be implied by exactOptionalPropertyTypes to avoid this unintuitive current behavior: const myObj = type({ key: "number = 5", }); // { key: 5 } const omittedResult = myObj...
Thanks for the info. I think what would be preferrable is something like:
The main point being that I'm not thinking of handling null, but rather just saying "Default myDuration to w/e is in
orElse".
Alternatively, what I would love is maybe something like:
Maybe that's too much magic and I'm not sure if there are limitations to the approach I mentioned, but it would be nice to be able to do custom keywords like thatwell the logic for default values like this already exists, although there's no way to string-embed non literal values.
you can use
type("number").default(() => Math.random()) to do this sort of thing, or a default value tuple if you prefer
the lack of a builtin concept of catch really seems to be the problem here, and I don't mind the idea of a fallback for a particular transformation. it gets messy when you expand the scope to encompass an arbitrary structural errors but if you want to create an issue to track implementation of a fallback for pipe I'd be interested in that.
for now my best recommendation if you are using this pattern a lot would be to build your own external generic abstraction around it to make it easier