Не используйте null для отсутcтвия состояния в UI

Сталкиваюсь с решениями разработчиков, когда они используют null для задания состояния UI по умолчанию. Мне такой подход не нравится 😡. У элементов обычно всегда есть начально состояние. Например, прогресс скрыт, данных списка нету, и др. Либо вовсе эти элементы не показываются и используется экран-заглушка

В коде я выражаю такое состояние следующим образом

private val _screenState =
    MutableStateFlow<ScreenState>(ScreenState.Default)

val screenState = _screenState.asStateFlow()

sealed interface ScreenState {
    
    object Default : ScreenState // Иногда называю None
    data class DataLoaded(...) : ScreenState 
    data class Loading(...): ScreenState
}

@Composable
fun MyScreen() {
    val state: ScreenState by stateFlow.collectAsState()
    MyScreen(state)
}

@Composable
fun MyScreen(state: ScreenState): Unit = when(state) {
    is ScreenState.Default -> Default(state)
    is ScreenState.Loading -> ProgressScreen(state)
    is ScreenState.DataLoaded -> DataScreen(state)
}

@Composable
private fun DefaultSceen(state: ScreenState.Default)

@Composable
private fun ProgressScreen(state: ScreenState.Loading)

@Composable
private fun DataScreen(state: ScreenState.DataLoaded)

также Default можно заменить на ссылку на другое состояние, и при этом не сломать код выше

sealed interface ScreenState {
    
    data class DataLoaded(...) : ScreenState 
    data class Loading(...): ScreenState

    companion object {
         val Default: ScreenState 
             get() = Loading(...)
    }
}

Использование null вместо Default приведет к неудобным аспектам работы с кодом:
1. Придется использовать null safety или операторы Flow для работы с null
2. Любые задания начальных состояний UI элементов придется привязывать не через поле в объекте состояния, а через связывание с null состоянием
3. Расширить/изменить null нельзя, а вот класс можно дополнить полями/методами и включить в анализ кода

#android #compose #AndroidBroadcast #БазаЗнаний