Is it a good practice for library (or any generic API) to return `StateFlow` or `SharedFlow` if the ...

# coroutines

[dimsuz]

Is it a good practice for library (or any generic API) to return StateFlow or SharedFlow if the particular flow behaves state-like or share-like? Or is it better to stick to Flow to be more generic? I was advised to do the latter, but oftentimes I find it useful to do something like onSubscription which is unavailable for Flow and having to do stateIn / shareIn when I know that underlying code already has `StateFlow`/`SharedFlow` somehow feels wasteful.

[Robert Williams]

StateFlow/ SharedFlow are both interfaces so there's no strong reason not to use them as a return type if it makes sense for your contract

[Robert Williams]

Does very much depend on how you want the API to be used though

[Robert Williams]

Note that in general having the consumer call stateIn / shareIn is not equivalent to allowing them to monitor the upstream flow

[dimsuz]

Yeah, sometimes I just want to explicitly specify that some flow has properties of "state": i.e. it will have values conflated and always emit last one on subscribe, and sometimes I want to specify that flow is "event-like", i.e no deduplication and no value on subscribe.

And I'd like to be able to communicate this through types rather than through docs.