TGViewer
YDC — Pizza Powered iOS YDC — Pizza Powered iOS @youngdacode · 242 subscribers
Post #138 243
😏 SwiftUI: почему Group всё ещё считается вредным

Почитал интересную статью от Two Cent Studios про контейнер Group в SUI – и она очень точно формулирует проблему, с которой многие сталкивались, но не сразу могли понять.

🍕 Что вообще такое Group
В SUI Group часто воспринимается как способ логически сгруппировать несколько View.
Он не участвует в layout и не появляется в иерархии, а лишь влияет на то, как SUI обрабатывает вложенные элементы.
И именно эта неочевидность часто становится источником проблем.

😫 Где начинаются проблемы
Group {
if isLoading {
ProgressView()
} else {
ContentView()
}
}
.onAppear {
fetchData()
}


Интуитивно кажется, что fetchData() вызовется один раз – при появлении Group.

Но на практике SUI распространяет onAppear на каждое View внутри Group.
В результате fetchData() может вызваться и для ProgressView, и для ContentView.

То есть логика внезапно начинает жить в двух местах, хотя визуально это вообще не очевидно.

🍕 Главный посыл статьи
Ключевая мысль статьи сводится к следующему:
Group чаще всего используется там, где логически должен быть отдельный View.

⚠️ Почему Group так легко превращается в проблему
- Group не изолирует логику
- Group не изолирует модификаторы и автоматически применяет их ко всем вложенным View
- скрывает реальную структуру экрана
- усложняет понимание body, особенно при условиях

Код выглядит компактно, но становится менее предсказуемым.

✅ Что использовать вместо Group
1. Вынос в отдельную View
Вместо:
Group {
Text("Title")
Text("Subtitle")
}
.foregroundStyle(.red)


Лучше:
HeaderView()
.foregroundStyle(.red)


- лучше читается
- проще переиспользовать
- легче тестировать

2. Реальные layout-контейнеры
Если важно именно как элементы располагаются на экране, а не просто сгруппировать код – подойдут:
- VStack
- HStack
- ZStack
- Grid
- Section

Они явно показывают структуру интерфейса, а не маскируют её.

3. ViewBuilder
Если Group появляется просто потому, что body стал слишком большим – это хороший сигнал к декомпозиции, а не к ещё одному уровню вложенности.

😅 В итоге
Group не решает задачу структуры интерфейса.
Он лишь влияет на то, как SUI обрабатывает вложенные View, не делая это очевидным из кода.

В результате логика жизненного цикла и применение модификаторов становятся менее прозрачными.

Практическое правило простое:
если в коде появляется Group, стоит проверить, не напрашивается ли здесь отдельный View.

#R #SwiftUI

👏
  • 💯 5
  • ❤ 3
  • 🔥 2
More from @youngdacode
  1. Mar 10, 2026😄 Статья CoordinatorKit 2.0: Production-Ready SwiftUI Navigation это пример честного разб…
  2. Mar 4, 2026☝️ 🚀 Как MCP-аналитика помогает AI-агентам кодирования принимать более «осознанные» решен…
  3. Feb 16, 2026☝️ В прошлом посте мы говорили про клиент-серверное взаимодействие: API, REST, запрос-отве…
  4. Feb 15, 2026☝️ 📦 Размер приложения — это не просто цифра в App Store Размер приложения напрямую влияе…
  5. Feb 13, 2026😏 Разберём разницу между some View и AnyView в SwiftUI. Тема не новая, но споры о правиль…
  6. Feb 9, 2026Вечернее-занимательное чтение. Пишет iOS разработчик с опытом, обзор на пост от iOS разраб…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →