#iOSКомпас 🧭1️⃣4️⃣5️⃣ Завдання 145Яка різниця між some View і AnyView, про яку важливо знати в SwiftUI?Доброго здоровля мої любі друзі. З вами ваш незмінний iOS розробник Сергій з @badlinkschannel.У SwiftUI постійно зустрічаються два схожі, але такі, що працюють по-різному, підходи: some View і AnyView. Для новачка різниця непомітна: і там і там повертається View. Але для SwiftUI це дві абсолютно різні історії, які впливають на те, як фреймворк буде оновлювати інтерфейс і споживати ресурси.🔣 Що ховається за some View:Коли ви оголошуєте var body: some View, відбувається щось на кшталт контракту з компілятором. Ви обіцяєте, що властивість повертатиме значення конкретного типу, який відповідає протоколу View, але сам тип залишається неназваним. Компілятор це влаштовує, він самостійно визначить тип на основі того, що ви написали всередині.Далі вступає SwiftUI. Отримавши від компілятора точну інформацію про типи всіх вкладених елементів, фреймворк вибудовує статичне представлення інтерфейсу. Це ніби SwiftUI заздалегідь знав повну схему екрану з усіма комірками, текстами та зображеннями. Завдяки цьому при зміні даних він може швидко зрозуміти, яка саме частина екрану потребує перемальовування, і оновити лише її.🔣 Як працює AnyView:AnyView працює інакше. Він стирає тип і залишає від конкретної в’юшки лише факт, що вона відповідає протоколу View. Для SwiftUI це означає втрату інформації: він більше не знає, що всередині - текст, зображення чи цілий стек. Усе, що залишається - чорна скринька.Типова ситуація, коли хочеться використати AnyView - повернення різних типів залежно від умови:func content(isLoggedIn: Bool) -> some View { if isLoggedIn { return HomeView() } else { return LoginView() }} Компілятору це не сподобається: типи різні, а some View вимагає один конкретний. Найпростіший, але неправильний спосіб полагодити - обгорнути обидва варіанти в AnyView. Код скомпілюється, але SwiftUI втратить інформацію про структуру і не зможе нормально оптимізувати оновлення.🔣 Правильний підхід - ViewBuilder:Замість ручного повернення і стирання типів SwiftUI пропонує використовувати @ViewBuilder. Цей атрибут перетворює набір View в єдиний вираз із типом ConditionalContent:@ViewBuilderfunc content(isLoggedIn: Bool) -> some View { if isLoggedIn { HomeView() } else { LoginView() }} Тип залишається конкретним і відомим компілятору, просто він уміє описувати умовну структуру. Усі переваги оптимізації зберігаються.🔣 Коли AnyView все-таки потрібен:Є ситуації, де без стирання типу не обійтися:➖ Масив в’юшок різного типу.➖ Інʼєкція в’юшки під час виконання, коли тип заздалегідь невідомий.➖ API, де не можна використати дженеріки.Наприклад, список різнорідних комірок, які приходять із конфігурації:let cells: [AnyView] = [ AnyView(ProfileCell()), AnyView(SettingsCell()), AnyView(NotificationCell())] Але навіть тут варто подумати: можливо, можна обійтися переліком з associated value або якимось іншим дизайном, що зберігає типи.🔣 Просте правило:Якщо SwiftUI може дізнатися тип на етапі компіляції - використовуйте some View. Якщо тип стає відомим лише під час виконання - використовуйте AnyView.AnyView сам по собі не зло. Зло - використовувати його як костиль, щоб швидко полагодити помилку компіляції, не замислюючись про наслідки для продуктивності.#️⃣ Різниця між some View і AnyView - це різниця між статичною типізацією з можливістю оптимізації та динамічною диспетчеризацією з потенційною втратою продуктивності. SwiftUI спроєктований так, щоб максимально використовувати інформацію про типи на етапі компіляції. Будь-яке стирання типів змушує фреймворк працювати всліпу, що рано чи пізно може позначитися на плавності інтерфейсу. Хороша звичка - завжди спочатку пробувати some View і лише в крайньому разі опускатися до AnyView, чітко розуміючи ціну такого рішення.@Zatishna_Galera