There’s one tooling “problem” (might just be me) w...
# compose
s
There’s one tooling “problem” (might just be me) with compose that I haven’t seen people discuss yet. When we do “Search usages” (Cmd/Ctrl + B) on a composable function, we get both references to it inside @Preview composable functions and in production code. I kind of wish there was a way to filter out the usages inside the previews because like 99% of the time it is not what I am looking for, and it only makes it so much slower to go into the production versions of them. It’s especially annoying that by default the pre-selected option that comes when clicking the shortcut is sometimes the preview one, and sometimes the production one. So it’s not consistent, making every time I click it a mini-game of me trying to figure read which one has the “Preview” suffix (picture attached). Does anyone else feel the same way? Any ideas to make this mild annoyance nicer?
5
l
I think it'd make sense to submit a feature request on https://goo.gle/compose-feedback
s
I haven’t done so so far because I don’t know what to suggest. I know I am annoyed by it, but if I just make a feature request with my complaint it helps nobody. I might just write basically what I wrote in this message, with my random ideas and go from there, see if anyone from inside Google has had this on their mind as well! Thanks btw Louis 🙌
b
There’s nothing stopping an
@Preview
Composable from also being production code.
s
That is true, and I am aware of it which only makes a possible solution to this even more complicated. Practically, in the code that I’ve been working on I’ve never found a case where I’ve done that, since most composables take inputs and then you depend on the callers to fill them, but regardless, I am sure some people use it that way and it’d be hard to account for them as well.
Created this https://issuetracker.google.com/issues/223240919 Please do chime in if you have opinions on this!
a
added @Chris Sinco [G] to it 🙂
👍 1
🙌 1