Імплементація ScrollViewDelegate Proxy для SwiftUI.
На основі рішення з попереднього мого посту (яке доречі сильно поліпшив та оптимізував, але про це окремо) зробив прототип ScrollViewDelegate view.

Це обгортка над ScrollView (яка також спрацює з List). Ця обгортка надає API, що має проксі функції делегату UIScrollViewDelegate.
1. ScrollView у якості контенту потрапляє в ScrollViewDelegate
2. Всередині ScrollViewDelegate відбувається пошук UIKit UIScrollView в контенті. І коли його знайдено - налаштовую ScrollViewDelegateProxy з ним.
3. ScrollViewDelegateProxy тримає в собі UIScrollViewDelegateProxy - по суті, той самий UIKit делегат для скролл вʼю.
4. UIScrollViewDelegateProxy імплементує необхідні методі, і що ВАЖЛИВО - треба зберегти оригінальний делегат, який використовував SwiftUI, щоб не поламати нативні реалізації.

Таким чином, викликаємо метод у ScrollViewDelegate, він передає кложур у ScrollViewDelegateProxy, який передає його у UIScrollViewDelegateProxy, де цей кложур викликається у відповідному методі делегату.

А оскільки оригінальний UIScrollView повертати назовні - небезпечно та недоцільно, я створив ScrollContext - структура, яка тримає тільки необхідні параметри UIScrollView, накшталт contentOffset.

ВАЖЛИВО: це не prod-ready код і не заклик до дії =) Це - прототип з playground-ідеями. Тому запрошую до обговорення, ідей та пропозицій =)

------------------------------
Я часто пишу і писав різні здебільшого технічні цікавинки на моєму Linkedin. Можеш підписатися, якщо було цікаво =)

Продовжую гратися з нутрощами SwiftUI.

Оновив підхід, про який писав раніше. Тепер пошук UIKit компонента відбувається не від Window через всю ієрархію (це і справді було тупо, хоча і не навантажувало), а від компоненту, через локальне розширення пошуку. Таким чином, тепер пошук UIKit-компонента починається зсередини, та рухається по принципу зацикленого перебору superview-subviews. Перевірку геометрії залишив.

Кода хоч і не багато, але я його опенсорснув, бо на його основі планую будувати декільки опенсорс-проєктів далі.

Також суттєво оновив-спростив код ще одного мого опенсорсу: SUI-InputModifier - модифікатор, який дозволяє бахнути кастомний InputView для будь-яких SUI-View.

Але SwiftUI може робити викрутаси накшталт підміни цілого компоненту без зміни його контейнеру (як це відбуваєтсья при заміні TextField axis).

Чому це проблема? Бо finder не викликає оновлення в updateView, тому що для нього айдентика не поміняється, бо finder є частиною контейнеру, а не його контенту, хоча по факту ми втратили цілий компонент.

Обійти це просто: прописати руками id для компоненту, який так себе поводить. У якості ідентифікатора ВАРТО використати причину втрати айдентики. Для TextField це Axis.

Але кейс мінімально розповсюджений =)

------------------------------
Я часто пишу і писав різні здебільшого технічні цікавинки на моєму Linkedin. Можеш підписатися, якщо було цікаво =)

------------------------------
І годі запитувати "Чому б не використати SwiftUI Introspect" - я знаю про його існування 😂 Але вважаю недалекоглядним прийняти це за даність та почати робити ніфіга 🗿Памʼятайте, догматизм шкодить розвитку!