Problem with RevealScope on hierarchy of components

[jayesh408]

Hey there, thank you developing this library. I'm loving it.

There's one issue I'm facing with RevealScope, as its required to keep Reveal() as topmost element in compose tree, it becoming very difficult to make nth element revealable if UI component resides in other file or somewhere other place but not in the same file. Due to this I've to make all my middle UI components as extension to RevealScope to transfer the scope all the way from root to nth element.

I hope you're able to understand my issue.

e.g
Reveal() (file: ScreenA)

• ScreenA (file: ScreenA)
• ComposableAa (file: ComposablesA)
• ComposableAb (file: ComposablesA)
• ComposableAc (file: ComposablesA)
  -- ComposableAca (revealable)((file: ComposablesAc))

as you can see, if I want to make UI component ComposableAca as revealable, since its not in the same file (ScreeA) I'll have to make ComposableAc as RevealScope.ComposableAc() and ComposableAca as RevealScope.ComposableAca in order to make it revealable.

[svenjacobs]

Hello Jayesh, I understand your problem 😃

As of version 0.0.14 it is not required anymore to only have one Reveal instance at the root of your compose hierarchy. You can have one Reveal instance per module or even per screen. Does this solve your problem?

Also if you need to pass down the RevealScope but the function already has a context receiver and as long as Kotlin does not support multiple context receivers, you can work around it by passing down the scope as a parameter like this:

Reveal(…) {
  Box {
    SomeComposable(
      revealScope = this@Reveal
   )
}

@Composable
fun BoxScope.SomeComposable(
  revealScope: RevealScope,
) {
  Text(
    modifier = with(revealScope) { Modifier.revealable(…) }
  )
}

However I recommend only having one Reveal and hence one RevealScope per screen. If you have multiple scopes in the hierarchy of a screen, transitions between two revealables might not look that nice when you have to call hide() on one scope and reveal() on another.

[jayesh408]

Okay cool, this also makes sense, as of now I'll work around this way. But can we have some kind of Annotations or some other way we don't have to pass the scope and still be able to call Modifier#revealable()

[svenjacobs]

Okay cool, this also makes sense, as of now I'll work around this way. But can we have some kind of Annotations or some other way we don't have to pass the scope and still be able to call Modifier#revealable()

The scope is — just like any other scope from the Compose framework (BoxScope, RowScope, etc.) — essential for the revealable() modifier and needs to be passed down. An annotation alone doesn't help here. Annotations make sense for code generation via KSP for example. But writing a compiler plugin and generating code for this use case is overkill in my opinion. Multiple context receivers are already experimental in the Kotlin language and will eventually be stable after Kotlin 2.0, which we can expect to be released this year. They will solve this problem so creating a workaround now seems unnecessary.

If your component doesn't have a context receiver, you can always use it to pass down the scope more elegantly.

@Composable
fun RevealScope.MyComposable(…) {
  Text(
    modifier = Modifier.revealable(…),
    text = "Hello world",
  )
}

[jayesh408]

Understood, yeah thank you man