Gabor Varadi

In a Kotlin world, what is the point of the `UseCase`? A simple function typealias `typealias LoginUser = suspend (Credentials) -> LoginResult` seems far better and more flexible in my opinion

I've been staring at this question for an hour, and my thoughts about it are converging on that the `LoginUseCase` contains a specific implementation of this `LoginUser` fun that you mention, but as it is a class, it has a name (type) by which you could find it from DI of choice.

Enjoyed it, you should write more often! LPT: use gist for code snippets, current one without syntax highlighting is difficult to read especially on mobile.

I also avoid the Jetpack ViewModel because I generally prefer to avoid scoping data to UI in favor specific user flows. For example, there may be a “registration” flow, so I create an object graph for all dependencies associated with that registration flow, accessible by IDs

Ooh. But who keeps the registration flow's object graph alive? And what kind of IDs are we talking about, string keys?

If the name represents either what it *is*, or what it *does*, then it's a decent name. I like DataSource, but a quick venture into the past tells me I also called the "RemoteDataSource" a "RemoteDataService", because it was triggering fetch tasks rather than return data directly