I’m looking at using the new type-safe compose nav...

# compose-android

[Michael Marshall]

I’m looking at using the new type-safe compose navigation. Curious as to why there’s no Route interface or class to inherit (or annotation), as it seems risky to be able to use any type T as a Route and accidentally pass in wrong classes.

[yschimke]

This has hit me, actually with companion objects on my data class.

[Ian Lake]

This is specifically covered in the blog post about the feature:
> One of the guiding principles we’ve followed in developing the Navigation Component is in trying to minimize how ‘infectious’ Navigation code is: e.g., how easy is it to swap out our library for another (no judgment!). If you have Navigation code and classes spread throughout your entire code base in every file, you’re never going to get rid of it.
> ...
> You’ll note that these [serializable classes] purposefully don’t need to implement any Navigation provided interface or even be defined in a module that has a Navigation dependency. Yet, they are enough to encapsulate a meaningful name of the destination (I think you might get some looks if you named it object Object1) and any parameters that are core to the identity of that destination.

[Ian Lake]

There a number of lint checks in work (see the pending code changes) on this issue that verify that the classes/objects you pass are at least Serializable though, but Serializable isn't something you can annotate APIs with, unfortunately: https://issuetracker.google.com/issues/339855424

[Michael Marshall]

A lint that checks any route you navigate() to is defined in your nav graph at compile time would be amazing - but probably difficult to make

[Atul Gupta]

but Serializable isn't something you can annotate APIs with, unfortunately I am sensing language feature request here 😅