Open rodrirepresa opened 2 weeks ago
When setting the navArgs in the destination annotation, the class is not the navigation argument, it’s just a class where navigation arguments are defined. So it doesn’t make sense for such a class to be a sealed type: you need a predefined set of arguments, you can’t tell the official nav lib “my arguments can either be these or these other”.
Im on the phone sorry for not formatting the reply, hopefully it’s understandable.
I’ve seen this confusion lately. Maybe I’ll enforce these classes to be named always SomehtingNavArgs to make it clear the args are its fields not itself.
Another thing: the class passed to Destination annotation navArgs does not need to be itself Parcelable or any other valid navigation type, precisely because it will not be serialised. Instead its fields will.
Issue Description: I am confused about the inability to use standalone sealed classes as navigation arguments (NavArgs) in our Destinations. However, I noticed that using data classes that hold sealed classes is allowed. This seems to be related to an issue with Kotlin Symbol Processing (KSP) when generating code.
Not allowed:
Allowed:
In my screen: