Использовал ли реактивный подход в проектах

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

Понимаете ли вы, что реактивность это работа с потоками значений во времени, и различаете ли инструменты.

Как отвечать

Рамка и пример.

> «Да. На прошлом проекте RxSwift, на текущем Combine, а новое пишу на async/await и AsyncSequence там, где хватает. > > Combine использую для того, для чего он и нужен: связывание состояния с интерфейсом и события ввода. Например поиск: debounce на полсекунды, removeDuplicates, flatMapLatest для отмены предыдущего запроса, и подписка обновляет список. Без реактивного подхода это писалось бы вручную таймером и флагами отмены. > > Где не использую: простой линейный запрос данных. Там async/await читается лучше, и цепочка операторов ничего не добавляет».

Что уместно назвать: Publisher и Subscriber, операторы (map, filter, combineLatest, debounce, flatMap), управление подписками через AnyCancellable и store(in:), @Published и ObservableObject как мост к SwiftUI.

Честные оговорки ценятся: у реактивного кода тяжёлая отладка (стек трассировки бесполезен), высокий порог входа для новых людей в команде, и легко получить утечку, забыв про [weak self] в подписке или не сохранив AnyCancellable.

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

Называют реактивным любой асинхронный код.

Не хранят подписку, и она немедленно уничтожается вместе с AnyCancellable.

Строят цепочку из десяти операторов там, где хватило бы одного вызова.

Не могут объяснить разницу между flatMap и flatMapLatest, а именно она решает проблему гонки запросов.