Suggestion: What if there is a preview button (next to @Composable functions) in the gutter just like Run button in psvm?

1 👁️ | @Composable
2    | fun Greeting(name: String = "Android") {
3    |    Text (text = "Hello $name!")
4    | }

That's really cute. File a feature request!

Wouldn’t this be more a AS plugin?

This should definitely be part of the Android plugin.

Except composables might require more scaffolding to work

@romainguy how would this affect the plugin and not the annotation?

I think he means that this would do the same as annotating

@Preview

and going to the preview screen.

My point is that it might not be possible to preview any composable as is.

Are you saying the

@Preview

annotation is pointless 🤔

Not at all. You can write a composable function with the data and scaffolding you need and annotate that with the preview annotation

So you insert information about the compostable inside the params of the

@Preview

annotation. Haven't seen that yet.

No, you write a composable function that does that

Oh, I see what you mean. Either way, a "Play" button on

PhotoCardPreviewDark

would be useful.

What would the play button do? The interesting thing about @Preview is that it will show you all previews in the current file at the same time

Maybe, just insert the text itself of the annotation? 😅

Eh, yeah 🙂

It can be a refactoring/quickfix/button that takes this

@Composable fun MyButton(size : Int)  = /**/

And generates this

@Preview 
fun MyButtonPreview(){  
    MaterialTheme( <--- cursor goes here first with a default value of lightTheme){
       MyButton( <--- cursor then goes here)
   }
}

I think I generally like

@Preview

more than a run button. Seeing all of the previews is nice. I think it’s a bit confusing with how it is presented though… I think my assumption was I’d just add

@Preview

to the component I’d use in production, that doesn’t seem to be the use-case though.

Considering you won't have the material theme, it's unlikely @Preview will be useful on a normal component

@Cody Engel You could, if your composable doens’t need any other setup

Are there many use cases for that? I started to extract the hello world sample and pretty quickly needed to pass parameters to the composables

Of standalone composables?

It's actually very similar to unit testing, some things don't depend on any data so you can just run them, and for some things you need mock data

So I wanted to add a Model to the sample which looks like this:

@Model
class Name(var name: String)

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            HelloForm()
        }
    }

}

@Composable
fun HelloForm(name: Name = Name("Android")) = MaterialTheme {
    val name = Name("Android")
    Column {
        Greeting(name = name.name)
        Button(text = "New Name", onClick = { name.name = "Cody" } )
    }
}

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}

You could put it in a separate file too

Making it private breaks it

Maybe that’s what we should do, make previews work when private

I will say though this tooling is still fantastic in the current state, I never thought I’d see Android get to this point and it’s really exciting 🙂

Late to this thread, but wouldn't you want to put preview functions in a different variant? I would think you'd want to avoid shipping the bytecode for them in your library/app.

You can do that, or use R8 to strip out the code that doesn’t get used

Putting the code in a separate build variant? I don’t think variants are really discussed much so making that a best practice seems weird... I think letting R8 do the heavy lifting would be more practical.