Closed pylebecq closed 4 months ago
@pylebecq can you check to see if it fixed this particular issue?
My use case desires the opposite behavior for default values. In my use case, i'm consuming CreateUser
documents from my datastore and know that because of the default values in the schema, the returned value must provide values for userId, name, and email. i.e. the object that I get back is of type { user: string; name: string; email: string }
and not of type { user?: string; name?: string; email?: string }
Hmm ... ok that's weird, because if you have a default it is optional ... apart from providing 2 distinct type for input / output, not sure how it could be resolved.
For now i've downgraded to 4.x. I think a couple paths forward are:
NonNullable<GeneratedType>
to mimic 4.x behavior in their codeYeah I think I'll go with the flag. That way if you want to use both, you can generate 2 sets of types if you need to.
Hopefully this would address everyone's use cases https://github.com/ovotech/castle/pull/47
@ivank #47 would satsify my use case, thanks!
I dont need to generate 2 sets of types, but I'm wondering how you recommend going about that for users who do. Wouldn't the namespaces/interfaces clash in terms of naming?
Wouldn't the namespaces/interfaces clash in terms of naming?
Possibly. This was a quick and dirty solution to make it solvable, but it’s far from the “pit of success” that would be needed.
Since ts offers rich ways to rename imports I doubt it would be a problem, just ... inconvenient.
@ivank I believe you are right. I thought namespaces would globally merge across files but that apparently doesn't happen by default! https://www.typescriptlang.org/docs/handbook/namespaces.html#multi-file-namespaces
This is valid
// a.ts
export namespace AvroDemo {
export interface Foo {
name: string;
}
}
// b.ts
export namespace AvroDemo {
export interface Foo {
name?: string;
}
}
Better late than never, I'm closing this as indeed it now works way better for my use case. Thank you @ivank .
Hello đź‘‹
I noticed something that I believe can be improved with default values. When using this Avro schema:
If I try to use it with avsc, I can supply only a
userId
for this object and this is valid because all other fields have default values:However, generating typescript definitions from this schema result of the following:
This means I must provide all keys when trying to create such an object. Otherwise, if I supply only the userId as I did with avsc:
I get the following error:
Is there any reason why the fields with default values are not generated as optional using
?
.