Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 Контент вільний від AI. Цей пост на 100% написаний людиною, як і все на моєму блозі. Насолоджуйтесь!

13.10.2024

Пошук в застосунку SwiftUI

Робив сьогодні пошук для власного застосунку — бо змісту стало достатньо, щоб без пошуку стало складно. Тут два спостереження.

По-перше, пошук — це складно! Навіть просто за рядком. Принаймні, якісний пошук. Та я не знайшов готових рішень. Пошук тільки починається зі збігів за підрядком. Але також обовʼязково треба ігнорувати регістр, причому не тільки в англійській мові — на щастя, зараз я бачу підтримку цього в більшості бібліотек для UTF-8. Далі, пошуковий рядок може міститись не в одному, а в декількох атрибутах обʼєктів, причому збіги в атрибуті “назва” повинен зʼявлятися вище, ніж в атрибуті “нотатки”. Тобто в нас зʼявляється до фільтра ще й ранжування.

Одним словом, розумієш, скільки всього гарного робить ElasticSearch. Знайшов теоретично два рішення: або Search Kit - фреймворк для системного пошуку macOS, який також здатний шукати в межах застосунку. Або повнотекстовий пошук SQLite FTS3 - SQLite взагалі відомий за простоту інтеграції, тож можна користуватися ним суто як рушієм пошуку. Але мені поки вистачає пошуку за підрядком. :)

По-друге, інтерфейс пошуку у SwiftUI виконаний через набір обгорток та користуватися ним досить неприємно, бо всі ці обгортки заплутують логіку. Спочатку є обгортка searchable() - її потрібно додати на… зміст навігаційного контейнера та це дасть там пошуковий рядок. Окрема обгортка searchSuggestions() дозволить описати, як показувати пропозиції результату. А вже всередині пропозицій є обгортка searchCompletion(), яка й робить компонент пропозицією, яку можна обрати. Трохи нагадує час HOC (компонентів вищого порядку) в React.

Принаймні ця архітектура майже не обмежує “бекенд”: ми вільні шукати як завгодно, утворювати пропозиції з будь-чого. Наприклад, за бажанням можна показувати останні переглянуті сторінки, коли рядок пошуку ще порожній або за відсутністю результатів.

Все це щоб зробити звичайний інтерфейс пошуку, як в будь-якому рідному застосунку macOS чи iOS (а точніше, в обох, бо код пошуку є переносним.) Веброзробники до того не звикли — та звісно, можна було взяти звичайне текстове поле та список та зробити з них пошук. Тільки “рідним” воно не буде, та й відтворити всі зручності не так легко.