Is there a way to restrict a function from being c...

# compose

[Doug McCluer]

Is there a way to restrict a function from being called outside the scope of a @Preview annotated function?

[Stylianos Gakis]

If https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/package-summary#LocalInspectionMode() is true it means you're being called from a preview afaik

[Doug McCluer]

@Stylianos Gakis That will allow you to determine, at run-time, if the function is being called from a Preview.

What I'm looking for is a compile-time check that will make the function unable to be called by anything not in the scope of a Preview. Similar to how the compiler will not allow you to call a Composable unless you're doing so from inside of another Composable.

[Vidmantas Kerbelis]

Weird use case, I'd say, but maybe nested functions are enough for you?

@Composable @Preview
private fun ExamplePreview() {
    @Composable
    fun createPreviewBox(
        color: Color,
        modifier: Modifier = Modifier
    ) {
        Box(
            modifier = modifier
                .background(color)
                .size(64.dp)
        )
    }

    Column {
        createPreviewBox(color = Color.Red)
        createPreviewBox(color = Color.Green)
        createPreviewBox(color = Color.Blue)
    }
}

createPreviewBox() in this case will not be accessible anywhere but your preview function

[Doug McCluer]

@Vidmantas Kerbelis That would make createPreviewBox only accessible within that one function, right? Other Previews wouldn't have access to it? I was hoping to find something that could be available to any Preview function, but could not be used in production.

There are a couple use cases we were hoping to support:
1. Creating mock/fake data to populate the UI in Previews
2. Adding a label/wrapper/decoration to all the Previews in the module that displays some helpful info to developers.
Both of these use cases involve some code that's only for internal use - ideally we wouldn't ship it with our app and we don't want developers accidentally using in their production code. We also don't want to have to move the implementation of the Preview into some other location separate from the implementation of the Composable being Previewed as that would reduce the helpfulness of the Preview.

[Vidmantas Kerbelis]

only accessible within that one function, right? Other Previews wouldn't have access to it?

Yes and yes.

[Vidmantas Kerbelis]

1. Creating mock/fake data to populate the UI in Previews

Use debug / release sources for that. On Android of course, it's controlled for you when you're switching build types, here you will have to control that yourself and point to those source sets yourself.

[Doug McCluer]

I considered source sets, but the thing there (aside from having to move the data setup into a separate folder) is - developers are almost always working in debug flavor. If we move some code into a debug source set, we'll get build errors when we eventually go to create a release build in CI, but it doesn't prevent developers from invoking those functions from their intended production code during development. That's better than nothing, but it would be so much more helpful if we could catch it during compilation of the debug build.

[Tgo1014]

Custom lint maybe? 😅

[Doug McCluer]

Yeah, that seems to be where we've landed 😅