I think this will get some hate from folks... but ...

# compose

[Colton Idle]

I think this will get some hate from folks... but is it that bad to use snapshot state in an App level state holder instead of something like StateFlow?

Example: Is this that bad? It's just so easy to use and I think the argument has been made before that snapshot state is a compose dependency, but it's not a compose UI dependency and so its similar to stateFlow in that respect.

@Singleton
class AppStateHolder() {
  var someBoolean by mutableStateOf(false)

[Filip Wiesner]

For me personally State > Flow (for this UC). You can always create Flow from Compose State using snapshotFlow 🤷

[Sean McQuillan [G]]

+1 snapshotFlow was added as an API to make this sort of usage reasonable

If you're doing a lot of reactive transforms, then State doesn't provide the best API

If you're doing state, it does what it says on the tin

[Colton Idle]

I'm just using this as state. As in... in my AppStateHolder I have a "currentUser". Would this be the right usage for stateFlow in your opinion @Sean McQuillan [G]? (also. idk if i mentioned it. loved your talk at dc NYC a while back.)

[Sean McQuillan [G]]

imo likely doesn't matter - but if you ever intend to consume the currentUser in another flow then I'd default to stateflow

[Sean McQuillan [G]]

cost to using mutableStateOf there is it would spider to a lot of code, making refactor hard if you ever did need the reactive version

[Sean McQuillan [G]]

and thx!

[Sean McQuillan [G]]

class AppStateHolder {
   val currentUser: StateFlow...

   @Composable fun currentUserState() = currentUser.collectAsState

Or the inverse

class AppStateholder {
    val currentUser by mutableStateOf...
    
    fun currentUserFlow() = snapshotFlow { currentUser }

[Sean McQuillan [G]]

hence why it's kinda just, whichever way you prefer is probably fine 🙂

[Colton Idle]

Cool. I think I'm going to go with this. Wanted to just make sure I wasn't doing something obviously bad.

@Singleton
class AppStateHolder {
  val someAppState: MutableStateFlow<Boolean> = MutableStateFlow...
  val currentUser: MutableStateFlow<User> = MutableStateFlow...

I think the only "bad" thing is that I'm using mutableStateFlow, but I think my only option would be to use a backing property and my team all kinda hates them so we dont use backing properties. /shruggie