https://kotlinlang.org logo
#compose
Title
# compose
y

Yoshio Schermer

02/24/2022, 8:08 AM
Is there something like this, so I don’t have to wrap every Preview Composable with my Theme?
Copy code
@Preview(theme = MyTheme)
@Composable
fun PreviewComposable(){
    Text(text = "foo")
}
a

Anand Verma

02/24/2022, 8:41 AM
I was also looking for the Same but didn’t find anything useful. So I thought to write own annotation processor for these case.
z

Zun

02/24/2022, 9:54 AM
Maybe make a live template which creates a preview composable that uses your theme?
y

Yoshio Schermer

02/24/2022, 2:32 PM
@Zun thanks, that at least make the process less tedious @Anand Verma haven’t written an annotation processor before, was it any hard to make it for this use case?
a

Anand Verma

02/24/2022, 2:34 PM
@Yoshio Schermer Yeah there lot to handle in annotation but we have different use cause. Live Template Seems Good And Easy Way.
👍 1
a

Adam Powell

02/24/2022, 3:10 PM
Write a composable that emits your content inside a stock preview theme you create:
Copy code
@Composable
fun PreviewComposable() = MyPreviewTheme {
    Text(text = "foo")
}
✔️ 3
Less typing than the proposed annotation too 🙂
y

Yoshio Schermer

02/24/2022, 3:35 PM
Yeah, but for every Composable I want to preview, I would need to wrap it into this MyPreviewTheme, right? Which gets a bit tedious when there are about a hundred to make. I was wondering if there is shorter way for this. Or perhaps like a theme I could set as default for all Preview’s I want to get rendered.
Setting a theme as the default for all Previews might not be so useful when having multiple themes. But, I think I’m making a correct guess that the great majority of apps don’t have multiple themes.
a

Adam Powell

02/24/2022, 4:52 PM
and you think typing
@Preview(theme = MyTheme)
on every preview composable is less tedious than adding
= MyTheme
before your opening
{
for the composable? 🤔
in general we try not to add annotations for things when a normal language construct will do. Annotations break the rules of the language in some way and are harder to reason about as a result. A wrapper composable has very specific rules it can play by.
z

Zach Klippenstein (he/him) [MOD]

02/24/2022, 7:14 PM
How many previews do you typically have in a file? Maybe a file-level annotation would be more convenient? (Not saying it's better, just trying to explore ideas)
c

Chris Sinco [G]

02/26/2022, 1:52 AM
This is a good discussion and something the team has thought about in terms of evolving the Preview annotation API. But what Adam suggested above is a clever tool (blew my mind today 🙂) that fits well into the Compose mental model and language constructs, and does scale about as well as adding a theme parameter to the Preview API 🤷‍♂️
y

Yoshio Schermer

02/28/2022, 8:32 AM
@Adam Powell Yeah, I 100% agree with your suggestion being better than the annotation one. I was more just shifting the discussion to having a default theme for all previews and whether that is possible and whether that is a good idea.
a

Adam Powell

02/28/2022, 3:46 PM
Where would such a default be defined? What convention or principles would the scope of that default appeal to? If someone were to drop a .kt file from a gist or other project into a new project, what would they need to know in order to produce the same preview results that they expected from its old environment? Is the payoff of that specialized knowledge worth it, or would it be better to be explicit in the manner outlined above?
It's also worth noting that a "theme" is a design library concept and not one that exists at the layer of compose-ui or IDE previews. It's just a series of CompositionLocals, and now that context receivers exist, some future design library might not use CompositionLocals at all
Does the IDE need to be patched for every design library that releases on maven central to support its concept of themes to fit into such a default theme feature?
Would some default theme or preview defaults framework need to be defined in order to make that sort of thing scalable?
I can't think of an expression of default theming that would be general enough to cover all concepts of theming that now and future design libraries might try to express that wouldn't be harder to learn and reason about than the expression syntax for a wrapper composable described above
👍 1
4 Views