https://kotlinlang.org
Join Slack
I’m going through updated docs on Compose state handling and I have one question regarding one appro...
# compose
k
I’m going through updated docs on Compose state handling and I have one question regarding one approach (more in 🧵 )
In this section, state holder is a simple class that hold state for the ui (and it’s logic). Fair enough.
There’s this property called 
shouldShowBottomBar
which has custom getter, which is marked as composable. Why is that?
In the example below (on the linked page) it’s being used as boolean value anyway, so why it’s being marked as composable? 🤔
z
I don’t see anything there that would require it, so given that the implementation is just a hand-wave I’m guessing it’s just to show that it’s possible? But I have no idea.
a
the example probably elided too much here. It doesn't need to be 
@Composable
unless the 
get()
function is reading a 
CompositionLocal
or something to make its decision
filed a bug for this page, thanks
k
Ah, make total sense
Thank you guys
btw @Adam Powell could you post a link to the issue? 🙏
a
the little bug filing link that shows up for us when viewing the docs pages internally doesn't file them in the publicly visible components, unfortunately 😕
k
ah, okay! Thought it’s the same public issue tracker
a
it sorta is, but depending on which component something is filed in, the visibility rules are different
the team that triages this kind of docs bugs funnels them through one that isn't public
✅ 2
a
I guess the code snippet for the doc has been taken from the Jetsnack sample. And the sample makes use of 
NavController.currentBackStackEntryAsState()
(which is a composable function) to determine 
shouldShowBottomBar
. That’s why the @Composable annotation was required there. Link to code.
✅ 1
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by