ankushg

    ankushg

    2 years ago
    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

    Robert Jaros

    2 years ago
    why do you use actual/expect serializers?
    can't you just define normal serializers for each platform?
    if you need same serialization based code in the common module, maybe just create an expect/actual helper function?
    ankushg

    ankushg

    2 years ago
    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

    Robert Jaros

    2 years ago
    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)
    I'm not sure it's possible, I'm just comparing your use case to mine