Что такое декларативный подход в UI

Что проверяют

Различаете ли вы описание состояния и последовательность команд, и понимаете ли, что из этого следует для кода. Для Android вопрос практический: он про переход от разметки с ручным обновлением виджетов к Compose.

Как отвечать

Императивно вы держите ссылку на виджет и сами приводите его в нужный вид: скрыть, поменять текст, выключить кнопку. Состояние при этом лежит в самих виджетах, и любая забытая ветка оставляет экран в противоречивом виде.

Декларативно вы описываете функцию из состояния в интерфейс. Меняется состояние, фреймворк сам вычисляет, что перерисовать. Ключевые понятия в Compose: composable-функция, состояние через remember и mutableStateOf, рекомпозиция только тех участков, которые читают изменившееся значение.

@Composable
fun Counter(count: Int, onIncrement: () -> Unit) {
    Column {
        Text("Нажатий: $count")
        Button(onClick = onIncrement) { Text("Ещё") }
    }
}

Здесь виден и второй принцип, подъём состояния: компонент не хранит счётчик, он получает значение сверху и отдаёт событие наверх. Данные идут вниз, события вверх, источник истины один.

Где спотыкаются

Сводят ответ к тому, что кода меньше и читается он приятнее. Это следствие, а не суть: суть в едином источнике истины и в том, что перерисовку планирует фреймворк.

Делают побочные действия прямо в теле composable: запускают запрос, пишут в переменную, показывают диалог. Функция вызывается произвольное число раз и в непредсказуемом порядке, поэтому запросы уходят дубликатами. Для этого есть LaunchedEffect и remember.

Меняют обычное поле класса и ждут перерисовки. Пока значение не наблюдаемое, система про изменение не знает и экран остаётся прежним, а выглядит это как «Compose не работает».