Anyone working with Kotlin, especially in the android world, has dealt with RequireOptIn. Actually they had to deal with the consequence of its application which is to explicitly opt-in into using a piece of code that is annotated with it.
@RequiresOptIn
In a nutshell, if you want the consumer of your code to be fully aware that they are about to use it, you annotate the code with RequiresOptIn and that forces the consumer to annotate the call site with OptIn.
Its like informing someone about the dangers of something and then having them sign that you have no responsibilities for anything that might happen to them.
@PreviewOnly
The problem
We have a composable, named renderList, that is part of module A and is being exposed to the rest of the project through another composable, named renderScreen:
renderList knows how to render List instances and we want to preview this rendering but in another module.
Using renderScreen is not possible because it also contains components that cannot be initialized when being in design time.
The solution
We are going to add one more composable in module A which will expose only the renderList:
and to prevent its usage in production code we are going to add some friction with the @PreviewOnly annotation which underneath leverages @RequireOptIn:
This way every call site of renderScreenPreviewer will end up in a compilation error unless the user explicitly opts in into its usage:
