Wrong SaveableStateHolder key generation

[Serpov]

Hi
package com.arkivanov.decompose.extensions.compose.jetbrains.stack
file Children.kt

line 56
private fun Any.key(): String = "${this::class.simpleName}_${hashCode().toString(radix = 36)}"

class Class1 {
data class Data(val data: Int)
}

class Class2 {
data class Data(val data: Int)
}

Class1.Data(1).key() -> "Data_1"

Class2.Data(1).key() -> "Data_1"

key should be different for inner data classes with the same names

[arkivanov]

This is a trade-off to avoid using configurations as keys (and so to avoid saving them in the Android Bundle). Currently, KClass#qualifiedName is not available in JS.

Assuming your configurations are defined as a sealed class/interface, or just a simple standalone class, this shouldn't be an issue. What's your use case?

interface SomeComponent {
    val stack: Value<ChildStack<*, ...>>
}

class DefaultSomeComponent : SomeComponent {
    override val stack: Value<ChildStack<Config, ...>> = ...

    private sealed class Config {
        data class Data1(val data: Int) : Config()
        data class Data2(val data: Int): Config()
    }
}

[Serpov]

Unfortunately, we cannot use sealed class for config declaration, because Data classes can be provided in different feature modules.

[Serpov]

Something like this

interface Feature1Contract {
       data class State(val data: Int)
       data class Config(val data: Int)
}

interface Feature2Contract {
       data class State(val data: Int)
       data class Config(val data: Int)
}

[arkivanov]

I see. It's advised to keep child configurations as implementation details in the parent component responsible for navigation. The parent is responsible for instantiating its children, and so it's the parent's responsibility to store all required information for child instantiation.

E.g. consider the following case.

class SomeChild(text: String)

class Parent1Child(...) {
    private val navigation = StackNavigation<Config>()

    val stack: Value<ChildStack<*, SomeChild>> = childStack(source = navigation, ...) { config, ctx ->
        SomeChild(text = config.text)
    }

    fun push(text: String) {
        navigation.push(Config(text = text))
    }

    private data class Config(val text: String) : Parcelable
}

class Parent1Child(...) {
    private val navigation = SlotNavigation<Config>()

    val stack: Value<ChildSlot<*, SomeChild>> = childSlot(source = navigation, ...) { config, ctx ->
        SomeChild(text = "Some text")
    }

    fun show() {
        navigation.activate(Config)
    }

    private data object Config : Parcelable
}

As you can see, it might be necessary to have different kind of configurations for the same child component. So it's definitely a responsibility of the parent.

Regarding the key generation. The best thing we can do is to add a selector function for Children, which will allow you to specify a stable key for each configuration.

fun Children(
    ...,
    key: (C) -> String = {  <default impl here> },
    ...
)

Would this work for you?

[Serpov]

Selector function for Children is a good idea and I think suitable for any cases with key generation. Thanks a lot

[arkivanov]

After further investigation, it appears that for JS we can use this::class.js.name (which gives unqiue JS name), then for other platforms we can use this::class.qualifiedName (which returns a full class name including package). I will investigate this further and improve. Thanks for raising!