Поиск с немедленной отменой
Отменить старый запрос до задержки нового
Реализуй Flow результата поиска. Каждый новый нормализованный запрос должен сразу отменять предыдущую ветку; новый непустой запрос начинает поиск после 300 мс тишины. Нормализация — trim; одинаковые подряд строки не перезапускают работу. Пустая строка отменяет поиск и эмитит пустой результат без этой задержки.
Условия: search кооперативно отменяем, возвращает список и не изменяет UI. Ошибки, кроме отмены, в этой задаче передаются коллектору. Результат содержит query, чтобы потребитель мог сопоставить его с текущим вводом. Отмена не отзывает уже доставленные или поставленные в выходной буфер результаты; немедленная отрисовка медленным коллектором не гарантируется.
Проверки:
" a ", затем"a"→ одна ветка."a"в 0 мс,"ab"в 100 мс → поиск толькоab, не раньше 400 мс.- Поиск
aуже запущен, затем приходитb→ веткаaотменяется сразу, поискbждёт 300 мс. - Пустой ввод во время поиска → пустой результат без ожидания.
Используется kotlinx-coroutines-core 1.11.0; transformLatest в этой версии требует ExperimentalCoroutinesApi. В обычном проекте тестируйте временные сценарии виртуальным временем.
Основа: debounce-кейс из draft/lifeconding.md, уточнённый моментом отмены.
Сохранённый код превышает предел редактора. Скачай его перед сбросом; исходная запись сохранена.
Задержка находится внутри отменяемой ветки. Каждый новый нормализованный query достигает latest сразу, отменяет прежнюю работу и создаёт новый delay. В цепочке debounce → latest отмена старой ветки была бы отложена до выхода query из debounce. transformLatest.
trim стоит перед distinctUntilChanged, поэтому изменения только краевых пробелов не запускают новый запрос. Результат помечен query; для повторных одинаковых запросов в более сложном UI понадобится отдельный request ID. Кооперативная отмена клиента не гарантирует отмену эффекта на сервере. Код разобран, но не запускался в Kotlin.
У transformLatest есть выходной буфер по умолчанию. Отмена текущей ветки не очищает уже эмитированные значения, поэтому UI должен сопоставлять результат с актуальным query/ID. «Без задержки» в условии означает отсутствие debounce-delay для пустой строки, а не гарантию времени отрисовки потребителем.