🧠 SwiftUI: Перестройка мышления с UIKit

Начиная изучать SwiftUI мы должны немного перестроить свое мышление. Это часто советуют уже опытные разработчики, когда переходят с UIKit. Важно не только хорошо изучить АПИ фреймворка, но и понять его философию. Так глубже и лучше поймешь применимость.

Собрал краткие советы с примерами.

🟣Декларативный vs Императивный подход
UIKit имеет императивный, где мы явно указываем КАК построить интерфейс. То SwiftUI декларативный, где мы описываем ЧТО должно отображаться.

🟣Состояние и данные
UIKit это про ручное обновление UI при изменении данных. SwiftUI про автоматическое обновление UI благодаря привязке к состоянию (@State, @Binding, @ObservedObject)

🟣Layout
UIKit чаще это про Auto Layout с constraints. SwiftUI в основе стеков (VStack, HStack, ZStack)

Как же перестроить мышление?

🔘Мыслите состояниями, а не событиями
UIKit это обработка событий и обновление UI. SwiftUI про обновление состояния, UI обновляется автоматически

🔘Композиция вместо наследования
UIKit часто использует наследование. SwiftUI строится на композиции небольших вью

🔘 Думайте о потоке данных
Используйте правильные property wrappers (@State, @Binding, @ObservedObject, @EnvironmentObject)

🔘Изучите жизненный цикл
Познакомьтесь с жизненным циклом SwiftUI (onAppear, onDisappear вместо viewDidLoad и т.д.). Это лучше даст понять легкость и простоту фреймворка.

🔘Модификаторы вместо прямой настройки свойств
В UIKit вы изменяете объект напрямую, присваивая значения его свойствам. В SwiftUI вы применяете модификаторы к представлению, и каждый модификатор создает новое представление с примененными изменениями. Где каждая операция возвращает новое неизменяемое вью

Какие советы вы бы добавили?

🌳 SwiftUI: View Trees vs Render Trees

Пережив атаку клонов возвращаемся к работе. Страсть к истиным знаниям им не затушить 😂

Многолетний опыт изучения всяких фреймворков мне подсказывает, что прежде чем изучать его SDK и API — нужно изучить принципы. Не бежать делать анимашки, архитектуры или вьюшки, а понять как и почему это все строится. Так можно сэкономить уйму времени в будущем.

В комментах прошлого поста поделились одной из важных ключевых концепций — понимание дерева вьюшек. В книге "Thinking in SwiftUI" пишется так:

View trees and render trees are perhaps the most fundamental and important concepts to understand to work with SwiftUI. To achieve the layout we want, we need to understand how view trees are constructed. To understand how state works in SwiftUI, it’s important to understand the lifetime of a view and how it’s related to the view tree we’re building. Understanding the lifetime is equally important to writing efficient SwiftUI code that only loads data and updates views when needed. Finally, animations and transitions also require an understanding of view trees.

Прежде чем что-то делать — нужно понять как строятся вьюшки: порядок их отрисовки; порядок компановки; передача состояния.

Познакомимся с фундаментальными концепциями, которые помогут не допускать баги и лучше понять поведение:

🟣View Trees — это эфемерный план, который создается и уничтожается при каждой перерисовке. Он описывает, как должен выглядеть интерфейс.

В SwiftUI это структура, которую мы описываем в коде. Представим что это чертеж дома.

🔘Render Trees — это реальные вью на экране, которые существуют между перерисовками и обновляются на основе view trees.

SwiftUI создаёт и обновляет его на основе View Tree, но не пересоздаёт полностью, а обновляет только изменившиеся части. Это дом, который построился по чертежу.

🔴Identity — это то, как SwiftUI отличает одну вьюшку от другой, особенно при обновлении интерфейса (ререндере).

Это метод как SwiftUI отличает одну вьюшку в плане между собой.

Почему это важно знать
- Перфоманс: SwiftUI умно обновляет только те части Render Tree, которые изменились, что делает приложение быстрее.
- Анимации: могут быть сломанные или корявые анимации
- Дебагинг: понимание разницы помогает разобраться, почему иногда ui выглядит не так, как ожидали.
- Правильная работа с состоянием: (@State, @Binding, @ObservedObject и т.д.): ты должен понимать, какие элементы остаются “живыми”, а какие будут уничтожены и пересозданы.

Скоро будет более полная статья в закрытой базе

Полезные статьи:
- SwiftUI Rendering and Identity
- A Day in the Life of a SwiftUI View

🐘 Подборка говнокода SwiftUI: Massive Views

Нельзя что-то изучить хорошо в вакууме. Статьи, видосы, LLM, книги и доклады — это только 1/5 реальной инфы из практики рядового работяги. Они не заменят реальную практику и опыт.

На опыте с UIKit и другими фреймворками я помню, что многие вещи, как кодстайл, бест практики и тп и тд нигде не фиксируются. Они приходят с реальной практикой и спорами с коллегами.

Реальный скилл набирается после сотен комментариев на кодревью. Поэтому решил собрать все худшие и лучшие практики.

Основные проблемы начинающих разработчиков:
🟣Огромные компоненты, которые не разбиты на подкомпоненты;
🟣Игнорирование жизненного цикла;
🟣Плохая производительность UI;
🟣Излишнее переиспользование модификаторов;
🟣Дублирование кода;
🟣Неправильная обработка асинхронных операций;

Разберем в данном блоке одну из проблем.

Massive Views — это классическая проблема любой системы. Когда вся логика и UI-элементы сосредоточены в одном большом компоненте, это создает ряд серьезных проблем. Детальней на скриншотах.

А вы кидайте свои примеры или комментарии.