Если бы мне пару лет назад сказали, что я буду писать отдельную статью про BoxScope, RowScope и ColumnScope, я бы, честно, усмехнулся 🙂 Тогда это казалось мелочью, какой‑то деталью внутренней кухни Compose. Но реальность разработки быстро ставит всё на свои места.
Сегодня я уверен: понимание scope‑подхода — это один из тех моментов, которые отделяют "просто верстаю экраны" от осознанной архитектуры UI. И да, я пришёл к этому не из документации, а через боль, ошибки и внезапные инсайты.
В этой статье я расскажу:
- как я сначала ненавидел align() 😅
- почему ошибка Unresolved reference 'align' — лучший учитель
- зачем вообще нужны BoxScope, RowScope, ColumnScope
- и почему иногда ограничение — это благо
Это не учебник. Это личный опыт. Поехали 🚀
Как всё начиналось: "Почему Modifier.align не работает?!"
Мой путь в Jetpack Compose был типичным. Ты пишешь что‑то вроде:
И ожидаешь, что кнопка просто встанет куда надо. Но компилятор смотрит на тебя холодным взглядом и говорит:
Unresolved reference: align
В этот момент обычно происходит одно из двух:
- Начинается гуглинг 🤯
- Или злость: «Compose какой‑то кривой»
Я прошёл оба этапа.
Первое ложное решение
Самое популярное решение, которое я видел (и сам использовал):
А потом:
Формально — всё правильно. Код работает. Все довольны.
Но спустя время внутри появилось странное чувство: что‑то здесь не так.
Первый звоночек: слишком много свободы
Через несколько экранов проект начал разрастаться. Появились:
- кнопки
- бейджи
- иконки поверх контента
- элементы, которые по определению существуют только в Box
И вот тут начался хаос:
- Modifier.align() используется где угодно
- один и тот же компонент можно случайно засунуть в Column
- UI ломается не сразу, а "где‑то потом"
Compose давал свободу. Слишком много свободы.
Момент озарения 💡
Однажды я наткнулся на сигнатуру:
И всё встало на свои места.
В этот момент я понял:
Scope — это не ограничение. Это контракт.
Что такое Scope на самом деле
BoxScope, RowScope, ColumnScope — это:
- не магия
- не синтаксический сахар
- а явное описание контекста, в котором компонент имеет смысл
Если функция объявлена как:
Это означает:
- она может быть вызвана только внутри Box
- она имеет доступ к align()
- она не может быть использована неправильно
Компилятор становится твоим союзником 💪
Почему ошибка Unresolved reference 'align' — это благо
Сейчас я воспринимаю эту ошибку как подсказку, а не проблему.
Она говорит:
Ты пытаешься использовать инструмент вне его контекста
И это прекрасно.
Локальные компоненты vs универсальные
Со временем у меня появилось простое правило:
🔹 Универсальный компонент
Используется:
- в Row
- в Column
- в Box
- где угодно
🔹 Локальный layout‑компонент
Используется:
- в конкретном месте
- в конкретном layout
- с конкретной ролью
И это нормально.
Почему я перестал бояться "жёсткой привязки"
Раньше я думал:
А вдруг мне понадобится переиспользовать компонент?
Но практика показала:
- 80% UI‑элементов никогда не переиспользуются
- они живут в одном экране
- и умирают вместе с ним 😄
Так зачем делать их универсальными?
Compose — это про намерения
Самое ценное, что дал мне Compose — это возможность выражать намерение кодом.
Читается как:
В этом Box есть кнопка настроек
А не:
Где‑то есть кнопка, которой зачем‑то передали align
Разница огромная.
Когда scope — это must have
Я всегда использую scope‑подход, если:
- элемент позиционируется (align, weight)
- элемент — overlay
- элемент — часть top bar / bottom bar
- элемент не имеет смысла вне контейнера
И почти никогда не использую его для:
- базовых кнопок
- текстов
- универсальных компонентов дизайна
Итог
Если коротко:
- Modifier.align не сломан
- Compose не багованный
- ты просто используешь инструмент не в том контексте
BoxScope, RowScope, ColumnScope — это:
- чистота
- безопасность
- читаемость
- архитектура
Сегодня я осознанно выбираю scope‑подход и почти никогда не возвращаюсь назад.
Если ты только начинаешь с Compose — поверь, этот инсайт сэкономит тебе много часов в будущем ⏳
Спасибо, что дочитал 🙌
Если статья откликнулась — значит, мы мыслим в одном направлении 😉