Combine Destination annotations about compose-destinations

[raamcosta]

One thing that may not have been clear, is that you can have any number of levels of this, so for example, lets say you want all your Destinations to be Dialogs (yes, stupid example ahah)

@Destination(style = DestinationStyle.Dialog::class)
annotation class DialogDestination(
    val navArgsDelegate: KClass<*> = Nothing::class,
    val wrappers: Array<KClass<out DestinationWrapper>> = [],
)

@DialogDestination(
    wrappers = [
        AuthWrapper::class
    ]
)
annotation class AuthDestination(
    val navArgsDelegate: KClass<*> = Nothing::class,
)

@AuthDestination(
    navArgsDelegate = SomeNavArgs::class
)
@Composable
fun SomeScreen() { ... }

[raamcosta]

Hi @Iliasgx !

This is one of the things I want to document better for v2, but this is already possible, although not exactly like that.
You can "compose" multiple Destinations by adding the annotation fields you want to be "overridable" in your annotation.

In your case:

@Destination(
    wrappers = [
        AuthWrapper::class
    ]
)
annotation class AuthDestination(
    val navArgsDelegate: KClass<*> = Nothing::class,
)

@AuthDestination(
    navArgsDelegate = SomeNavArgs::class
)
@Composable
fun SomeScreen() { ... }

You can literally open Destination annotation class file and copy fields from there that you want to allow usages of your annotation to use.

Let me know if this works!

[Iliasgx]

Sure this will work in this case, thank you!

I was more thinking about the @Preview way of Compose to combine them such as:

@Preview(name = "Font - Default", group = "Font Scale", fontScale = 1f)
@Preview(name = "Font - Large", group = "Font Scale", fontScale = 1.5f)
annotation class FontScalePreviews

@FontScalePreviews
@Preview(name="Another preview type")
@Composable
fun SomeComposable() { ... }

That would allow annotations for specific cases used around the app such as @AuthenticatedDestination, @FlagSecureDestination etc. But doesn't pollute the annotations with overrides for possible NavArgs or DestinationStyles that have nothing to do with the used annotation classes.

However, wonderful the combination with overrides is already possible!

[raamcosta]

The issue with repeatable Destination is that it means a different thing that is also possible with v2. You will be able to have multiple Destinations in a given Composable and we will generate one Destination for each of those.

So in our case 1 Destination annotation = 1 generated Destination. I like it better this way :)

I don't fully understand this part though:

But doesn't pollute the annotations with overrides for possible NavArgs or DestinationStyles that have nothing to do with the used annotation classes.

I don't see it as pollution at all, I think it makes it explicit what usages of that annotation can control. Because if my annotation already controls one aspect of the "Destination" concept, then it should not allow usages to override that aspect.
Any Destination annotation (no matter if mine or yours) is the same "concept" and this concept has many characteristics which you inherit implicitly or explicitly, so again, "nothing to do" is not really true, in my eyes it has everything to do with it!

[Iliasgx]

@raamcosta Does this require a special setup for multi-module projects? When the @AuthDestination annotation class is located in another module, the destinations I annotate with it are no longer generated.

[raamcosta]

Hmm try adding retention BINARY to AuthDestination, otherwise annotations are not really present to other modules.

But, I suspect it still won’t work, no.

FWIW, on v2 you’ll be able to add wrappers in the module that’s importing the destinations.

[raamcosta]

I mean this to your AuthDestination annotation:

@Retention(AnnotationRetention.BINARY)