I'm still very much learning about coroutines (and the difference between dispatchers vs threads) but I always found the fact of why viewModelScope.launch uses the main thread by default as an interesting choice. I suppose the answer in this SO question make sense, but does anyone have a more canonical answer as to why main dispatcher is used? https://stackoverflow.com/questions/62166878/why-does-viewmodelscope-launch-run-on-the-main-thread-by-default

Helps to remember a fundamental principle of suspend funs - they should always be main-safe https://developer.android.com/kotlin/coroutines/coroutines-best-practices#main-safe

Makes sense. So in the case of me writing a callBack flow that's why it's good practice for me to use flowOn? example:

fun getBooks(): Flow<List<Book>> {
  return callbackFlow {
    val listener =
      FirebaseFirestore.getInstance()
        .collection("books")
        .addSnapshotListener { value, error ->
          trySend(value to error)
        }
    awaitClose { listener.remove() }
  }
  .doSomethingWithNullValueAndError() // Depends. It might be better after conflate
  .conflate()
  .map { (value, _) -> 
    value.toObjects()
  }
  .flowOn(defaultDispatcher)

So with the callBack flow example... firestore handles the threading... and then the cpu bound .map is offloaded to a different dispatcher via flowOn. Okay. I think as a whole my entire project is starting to make a lot more sense now. Thanks @Robert Williams for teaching!

Exactly, with flows it's the collection code that needs to be main-safe but that typically involves walking back through the full chain of operators which built the flow

viewModelScope is not just Dispatchers.Main, it's Dispatchers.Main.immediate. which means that if you're already on the main thread, launched coroutines will be run immediately (up until a suspension point) instead of being posted to the next frame