TopicViewModel TopicUiState NewsUiState Result generic class

[mobilekosmos]

Hi all, just wondering why you are using a separate UiState for each screen like TopicUiState and NewsUiState when they all share the same properties, I suppose you could use the more generic class Result or another more generic class using generics? Just trying to understand if there are specific reasons why using explicit sealed class for each screen.

[SimonMarquis]

@mobilekosmos I think this is no longer the case.
They probably were at some point early in the development phase, but right now they have different types:

sealed interface TopicUiState {
    data class Success(val followableTopic: FollowableTopic) : TopicUiState
    object Error : TopicUiState
    object Loading : TopicUiState
}

sealed interface NewsUiState {
    data class Success(val news: List<UserNewsResource>) : NewsUiState
    object Error : NewsUiState
    object Loading : NewsUiState
}

I think you close this discussion 👍

[mobilekosmos]

The question is, what are the advantages of layering this?, you are just duplicating what the Request Result class already has (just because of separation of concerns?). In a really big project we used always a generic Result class in the Repository and also in the UI layer, which works without problem, I tried to introduce the idea of layering this and adding a UIState to each ViewModel and they looked at me like a maniac 😅 so don't know how to argument this boilerplate.

[SimonMarquis]

Yeah, I think this was mainly for separation of concerns. There might be a case where we need to add specific data to the "loading" state for example, and adding generics on top of it would not necessarily simplify it.
And at the moment, the sealed interface Result<out T> is used between the ViewModels and the Repositories to have a generic way of handling repository calls. But then, it's up to the "mappers" to inflate whatever UiState.
Maybe the maintainers can clarify this :)