I'm working in a multiplatform project where we ha...

# serialization

[ankushg]

I'm working in a multiplatform project where we have a few actual typealias MyClass = String for some platforms, while using actual data class MyClass(val someVal: String) on other platforms. We also have an expect val MyClassSerializer: KSerializer<MyClassSerializer> which we set equal to either StringSerializer or the generated serializer for the data class. We declare contextual(MyClass::class, MyClassSerializer) in our common serialization context.

On platforms where we typealias to Strings, we get a SerializerAlreadyRegisteredException: Serializer for class String already registered in this module , even though our MyClassSerializer points to the built-in StringSerializer.

Is there a way to avoid this error?
• I see the overwriteWith option, but it feels scary to use this since I'd be overwriting behavior for ALL Strings. It seems easy to declare a custom serializer for a type without realizing that this might change behavior for every String in your app.
• My understanding is that using an inline class instead of typealias might help here, but I'm not sure about the state of inline classes in multiplatform.
• Can I contextually register a serializer if-and-only-if there isn't already one registered for the type?
• Is it possible for the contextual registration to do an equality check on the KSerializer and not throw an error if we're just redeclaring the preexisting association?

[Robert Jaros]

why do you use actual/expect serializers?

[Robert Jaros]

can't you just define normal serializers for each platform?

[Robert Jaros]

if you need same serialization based code in the common module, maybe just create an expect/actual helper function?

[ankushg]

Ideally we'd have one common SerialModule that doesn't know/care about the underlying implementation details for how each platform represents classes…

I guess we could work around this issue by building platform-specific SerialModules for classes relying on expect/actual and then use include to pull them into the global SerialModule we define in Common?

[Robert Jaros]

maybe it would be enough to have one serialmodule in common, but just register it in platform code (only where the actual class is not String)

[Robert Jaros]

I'm not sure it's possible, I'm just comparing your use case to mine