-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle generic properties and classes #11
Comments
- fix element ID name extraction (handle other SerialDescriptors that have < > in them) - fix knit tests not running - fix generic test #11
- workaround for json content polymorphic + test - fix element ID name extraction (handle other SerialDescriptors that have < > in them) - fix knit tests not running - fix generic test #11
I suspect this will be far too difficult to implement in a nice way. SerialDescriptors don't have any clear 'generic type' information, or if they do then it's very difficult to determine what TypeScript should be produced. It might be possible with reflection, and clever use of a SerializersModule? For now, generics are implemented as 'best effort', but I think they should safely fall back to TODO document generics limitations #19 |
Generic types are very important, and this limitation of Kotlinx.serialization makes me think it should be thrown out of the window and replaced with a KSP processor. |
Hi @natanfudge, thanks for the comment. Would you be able to provide a specific use case where you need generics? What Kotlin class do you need to use? What Typescript code do you want to be generated? What does kxs-ts-gen currently generate? Are there any workarounds? It would help inform any decisions. I've always found that it's best to avoid using open-polymorphism with Kotlinx Serialization completely, and that refactoring to use closed-polymorphism will be more work, but it is much more robust and leads to better Typescript. This library does get used, I can see ~500 downloads last month for the JVM artifact, so it's very much alive and I'm open to evolving it, although I have less time as of late. |
data class SearchResult<T> {
val items: List<T>
val page: Int
} Generates interface SearchResult<T> {
items: T[]
page: number
} Used like fun getDogs(query: String) : SearchResult<Dogs> As an API endpoint for example |
Thanks! Just to be clear, can you specify what you want kxs-ts-gen to generate vs what it actually generates? |
Considering interface SearchResult {
items: string[]
page: number
} Which doesn't involve generic types. I've investigated @Serializable
data class PlayerId(val num: Long)
@Serializable
data class GenericThing<T1, T2, T3>(val x: T1, val y: T2, val z: T3, val w: List<T3> = listOf()) This is how it looks like as raw json type info: "models": [
{
"name": "PlayerId",
"properties": {
"num": {
"name": "Long"
}
}
},
{
"name": "GenericThing",
"typeParameters": [
"T1",
"T2",
"T3"
],
"properties": {
"x": {
"name": "T1",
"isTypeParameter": true
},
"y": {
"name": "T2",
"isTypeParameter": true
},
"z": {
"name": "T3",
"isTypeParameter": true
},
"w": {
"name": "List",
"typeArguments": [
{
"name": "T3",
"isTypeParameter": true
}
]
}
}
},
] Which is modeled after: @Serializable
data class RpcModel(val name: String, val typeParameters: List<String> = listOf(), val properties: Map<String, RpcType>)
@Serializable
data class RpcType(val name: String, val isTypeParameter: Boolean = false, val typeArguments: List<RpcType> = listOf()) And the Typescript output I've yet to generate. |
This has a large scope. SerialDescriptors are not at all generic. It is probably impossible to get this information from KSX.
The text was updated successfully, but these errors were encountered: