A
arktype•5w ago
log1st

Issue with Default<> in Type as generic.

I'm trying to create a generic function that accepts type returns other type. 
export const generic = <t = unknown, $ = {}>(filter: Type<t, $>) =>
  type({
    take: "number.integer = 10",
    filter: filter,
  });
export const generic = <t = unknown, $ = {}>(filter: Type<t, $>) =>
  type({
    take: "number.integer = 10",
    filter: filter,
  });
But if I'm trying to pass something that contains defaultable type it throws error: 
const example = generic(type({
  slug: `string = "defaultSlug"`
})); // It says Type Default<string, "defaultSlug"> is not assignable to type string
const example = generic(type({
  slug: `string = "defaultSlug"`
})); // It says Type Default<string, "defaultSlug"> is not assignable to type string
Looks like there's a problem in my usage of Type generic. Cause if I create type without generic function it works perfectly.
10 Replies
ssalbdivad
ssalbdivad•5w ago
That is a weird issue! It seems like TS prefers if the type is inferred as a whole: 
export const generic = <t extends type>(filter: t) =>
    type({
        take: "number.integer = 10",
        filter: filter as type.cast<t["t"]>
    })

const example = generic(
    type({
        slug: `string = "defaultSlug"`
    })
) 
export const generic = <t extends type>(filter: t) =>
    type({
        take: "number.integer = 10",
        filter: filter as type.cast<t["t"]>
    })

const example = generic(
    type({
        slug: `string = "defaultSlug"`
    })
)
Or perhaps better yet, accept a definition so you don't have to wrap what you pass in (you can still pass in a type instance since they're also valid definitions: 
export const generic = <const def>(filter: type.validate<def>) =>
    type({
        take: "number.integer = 10",
        filter: filter as type.cast<type.infer<def>>
    })

const example = generic({
    slug: `string = "defaultSlug"`
})
export const generic = <const def>(filter: type.validate<def>) =>
    type({
        take: "number.integer = 10",
        filter: filter as type.cast<type.infer<def>>
    })

const example = generic({
    slug: `string = "defaultSlug"`
})
log1st
log1stOP•5w ago
Awesome, @ArkDavid ! Thank you very much. Also i had a question about serializing ArkErrors before. Is it possible?
ssalbdivad
ssalbdivad•5w ago
Yes! I added a toJSON() method so you can use that (it will happen by default if you JSON.stringify them)
log1st
log1stOP•5w ago
What about deserializing? I'm usting superjson to serialize errors and deserialize after in responses to use features of traversal and etc.
ssalbdivad
ssalbdivad•5w ago
Hmm I haven't built anything yet but it's basically an identical structure to ArkErrors. Technically ArkErrors has some non-serializable stuff like a Traversal for the current data being checked that provides context for errors, so that would not be deserializable. I think you could just JSON.parse() it and cast to ArkError[] ?
log1st
log1stOP•5w ago
That's what I'm doing now. But as I know ArkErrors contains context? How can I extract that context during serialization?
ssalbdivad
ssalbdivad•5w ago
What are you wanting to do exactly you can't do with an ArkError[]? It wouldn't usually make sense to add new errors to a serialized/deserialized error list
log1st
log1stOP•5w ago
Some of my services may add errors during call stack between them. I didn't see toJSON before, looks like it's new feature. I think that's enough for me. I'll make workaround with that structure. Thank you.
ssalbdivad
ssalbdivad•5w ago
It is new! I added it a couple releases ago to allow serializing errors. You can push new errors to the ArkError[], you just can't use methods like .add that collapse errors at common paths on ArkError. That fundamentally wouldn't make sense to deserialize since ArkErrors is supposed to be associated with a single data validation traversal But almost all the actual error context is encoded in each ArkError so you should be fine
log1st
log1stOP•5w ago
Got it! Thanks.

Did you find this page helpful?