Generate exportable external interfaces for encodeToDynamic/decodeFromDynamic
See original GitHub issueWhat is your use-case and why do you need this feature?
We use kotlinx.serialization
to map json strings from our API response into Kotlin data classes.
We also use kotlinx.serialization
to
- map our Kotlin
data class
es into standard JS objects usingencodeToDynamic
for JS consumers of our KMP library and - JS Objects back to
data class
es usingdecodeFromDynamic
when JS consumers pass in data
This is great because it allows us to reuse our existing serialization logic for network requests, while exposing data in a shape that JS consumers expect.
It’s much faster than manually declaring external interface
s for each data class
and writing mapping methods.
However, these methods only return/consume dynamic
. This means that we don’t get Typescript definitions like we would with a standard external interface
in the new JS IR Backend.
Ideally, we would be able to have external interface
s generated based on our SerialDescriptor
s, and be able to export them for use in our JS clients so they know what to expect.
Describe the solution you’d like
- Serializer walks through the
SerialDescriptor
s for each option - Serializer generates
external interface
representations of what it’s spitting out- acceptable if there are reasonable limitations on what can be converted to an
external interface
- acceptable if there are reasonable limitations on what can be converted to an
- allows users to mark
external interface
with@JsExport
to get type definitions encodeToDynamic
can be cast to that generatedexternal interface
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (6 by maintainers)
Top GitHub Comments
@ankushg Hi, I’ve written a prototype library that will generate TypeScript interfaces based on
@Serializable
classes.https://github.com/adamko-dev/kotlinx-serialization-typescript-generator
Generated TypeScript interface:
Is this useful for you? It’s not finished, but if you have any thoughts, please let me know.
@aSemy Looks great!
I assume ticket can be closed now, as I said, this is a bit out of scope of the core library