Hardcoding scope parameter for a "typealias" of metro annotations

[ursusursus]

Hi,
I'm exploring Compose Navigation3 library, and there there is this dsl-y setup

entryProvider {
    entry<Home> {
        HomeScreen { backStack += Detail(it) }
    }
    entry<Detail> {
        DetailScreen(it.id)
    }
}

This won't scale to a big team as you need to add the entry manually - so obvious choice is then multibinding.

This is my prototype

@Inject
@ContributesIntoSet(AppScope::class) <-----------------
class HomeScreenEntry : ScreenEntry {
    override fun EntryProviderBuilder<NavKey>.registerEntry(backStack: NavBackStack<NavKey>) {
        entry<Home> {
            HomeScreen(
                onGoToProduct = { backStack += Detail(it) }
            )
        }
    }
}

and note I'll have multiple semantic scopes (AppScope, UserScope, WorkspaceScope etc). My gripe with this is that obviously @ContributesIntoSet needs a scope parameter & AppScope is technically correct means to collect all the entries across the app, however it's a parameter nonetheless & I feel people will try to plug say UserScope there thinking it changes the behavior somehow, which won't happen -- a space for errors.

I was thinking of having something like

typealias annotation ContributesScreenEntry = dev.zacsweers.metro.ContributesIntoSet(AppScope::class)

as means of "hardcoding" the scope so it's no longer an option

which obviously doesn' work as it's a made up syntax, so I tried a bit harder

@Retention(AnnotationRetention.RUNTIME)
@Target(AnnotationTarget.CLASS)
@dev.zacsweers.metro.ContributesIntoSet(AppScope::class)
annotation class ContributesScreenEntry

which then fails to compile with

`@ContributesIntoSet` is only applicable to constructor-injected classes, assisted factories, or objects. Ensure sk.ursus.metrodemo.home.ContributesScreenEntry is injectable or a bindable object.

Is this a deadend?

[ZacSweers]

sidebar: please use syntax highlighting when writing larger code snippets for readability

[ZacSweers]

Yeah the syntax you are writing is a dead-end. As you mentioned, it's a made-up syntax that Metro doesn't understand. You likely want to write some sort of code gen of your own that generates what metro needs, similar to how Circuit's code gen generates contributing factories for its presenters/uis.

[ursusursus]

Okay so ContributesIntoSet will never ever have target of ANNOTATION_CLASS?

I'll look into the custom codegen then, thanks!

[ursusursus]

If might have a follow up, as I'm yet to do custom codegen - if I were to have a custom annotation which is then picked up by my processor which then spits out metro @Provider stuff to get the equivalent behavior - how do you think that will affect the build time performance, if I were have say 100 such callsites? (you touted metro perf due to being a compiler plugin vs ksp di libs - so I'm curious)

Basically what I'm asking if I won't eat through the perf gains of metro (over say anvil) with this - and maybe I should do a custom lint check that enforces the correct usage instead?