For navigation compose type safe, has anyone writt...
# compose
a
For navigation compose type safe, has anyone written lint checks for common mistakes (using nested serialized classes without nav types, enums, unsupported parameter types even though valid in kotlinx serialization)?
Having runtime crashes are not fun, which can get mitigated by an integration test
i
Note that the later two are going to be handled for you in this next beta: enums and every type are going to be supported by default
a
By “every type” do you mean everything kotlinx serialization supports?
i
Any primitive type with any nullability, yes
a
Ah the issue I filed ! thank you color
i
It was a bit too late for this release, but we are also looking at what we can do to make nested Serializables easier to use for the next release e.g., having a serializableType<YourType>() you can use
a
Oh that would be great, you would then just pass that into the type map?
i
That's the idea, yeah. Ideally with a quick fix lint
🎉 1
s
For now this is what I've done Andrew, after the discussion which took place here: https://github.com/HedvigInsurance/android/blob/30cdff3adb19a591a3a5e84b476c49c107[…]om/hedvig/android/navigation/compose/JsonSerializableNavType.kt Just encode everything as a string, relying on kotlinx.serialization since it can handle all scenarios like nested serializable types etc. And for a destination like:
Copy code
@Serializable
data class DateOfOccurrence(
  val dateOfOccurrence: LocalDate?,
  val someprimitiveWhichDoesNotRequireACustomMap: String,
  val maxDate: LocalDate,
  val info: Info,
) : Destination
I pass in
Copy code
typeMapOf(
  listOf(
    typeOf<LocalDate?>(),
    typeOf<Info>(),
    typeOf<LocalDate>(),
    ... more custom types if required here
  )
)
And so far this seems to work for me.
a
ohh interesting Stylianos - that would work nicely for small nested elements. larger ones obviously may not be ideal to turn them into strings.
s
Yeah I don't know how nested your destinations are, I would hope not so much that this string ends up being megabytes long right? 😅
a
ha…our app has a lot of legacy things gone wrong, like large datamodel objects that contain large response java models with optional fields…without refactoring 120 fragment newinstance methods, ive resorted to just shoving the data into an intermediate state holder and pulling it out the other side when navigated in compose and rendered in
onCreate
. 😄
🫂 1
s
I regret asking ☠️
sad panda 1
😂 1