https://kotlinlang.org logo
Join Slack
Powered by
Is there something like this, so I don’t have to w...
# compose
y
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
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
Maybe make a live template which creates a preview composable that uses your theme?
y
@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
@Yoshio Schermer Yeah there lot to handle in annotation but we have different use cause. Live Template Seems Good And Easy Way.
👍 1
a
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
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
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
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
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
@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
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
Open in Slack
PreviousNext
Powered by