Regarding `collectAsState` is it more appropriate to have :one: `val user = appStateHolder.currentU...

# compose

[Colton Idle]

Regarding collectAsState is it more appropriate to have

1️⃣ val user = appStateHolder.currentUser.collectAsState().value
or
2️⃣ val user = appStateHolder.currentUser.collectAsState()

[agrosner]

for 2️⃣ you could do

val user  by appStateHolder.currentUser.collectAsState()

right?

[Colton Idle]

Hm. Could you? The way I stumbled upon this was that I was doing a bunch of user != null checks while using option 2. The IDE told me that the checks weren't necessary so I removed them and then figured out that I was doing a != of my stateFlow and not the actual value of the stateFlow.

[Colton Idle]

Tried that and although it compiled, I couldn't actually do user.getSomeField due to an error.

[agrosner]

whats the error? but whats user.getsomeField ? hows that relate to currentUser.collectAsStatE()?e

[Colton Idle]

I tried user.username for example and I got a compile error of

"Smart cast to 'AppUser' is impossible, because 'user' is a property that has open or custom getter"

[agrosner]

Looks like it's a computed getter and not cached?

[Colton Idle]

Hm. Just updated to user?.username and it works. Cool. Didn't think of using by

[agrosner]

By just unwraps the state property using a delegate and tells compose of its changes. So you would have same thing if you used = and value accessor

[itnoles]

I have seen collectStateWithLifecycles from no win Android apps