В песочнице для iOS мы выбрали немного другую механику. Там мы делали песочницу уже после Android, так что был взгляд со стороны, что хорошо и что плохо. В итоге получилось похоже, но со своими отличиями 👁

И пока андроидик отдыхает после рассказа, к доске подходит иосик

iOS: Макросы + Build Tool Plugin 🦾

Был выбран путь сделать полностью контролируемую песочницу, где каждый параметр компонента должен быть отмечен и задан явно

Основная идея такая же — компонент отмечается макросом Playground

@attached(peer, names: suffixed(_Playground))
public macro Playground(
  _ name: String,
  in location: CatalogPath,
  status: ComponentStatus = .active,
  presentation: PlaygroundPresentation = .page,
  previewLayout: PlaygroundPreviewLayout = .sizeThatFits,
  designVersion: String = "1.0"
) = #externalMacro(
  module: "PlaygroundMacroPlugin",
  type: "PlaygroundMacro"
)

Но различие в том, как и какие параметры попадают в плейграунд

Механика плейграунда на iOS такая:

1. Пометить компонент макросом @Playground

2. Если у компонента есть параметры — разметить ВСЕ поля его модели @PlaygroundParam либо @PlaygroundIgnore. За полноту разметки отдельно следит CI-линтер.

3. Макрос разворачивается компилятором в отдельный тип PlaygroundComponent с методом component(knobs:), который возвращает View — аналог PlaygroundProvider на Android

4. На этапе сборки Build Tool Plugin сканирует swift файлы, запускает кодогенератор и на выходе получает манифест модуля PlaygroundManifest со списком всех найденных компонентов.

5. При открытии песочницы, содержимое манифеста регистрируется в singleton реестре. Он оборачивает фабрику View компонента в экранный контейнер, готовый для отображения в плейграунде.

Итого на песочнице iOS:
⭕ Компоненты строго типизированы и вероятность райнтайм крашей минимальна
⭕ Для каждого параметра явно задается своё default значение рядом с местом объявления. Видно прямо в коде компонента, а не в отдельном файле
⭕ Для компонента можно даже создать "фабрику стейтов", которая нарисует переключатель стейтов в песочнице. Удобно, чтобы проверять полноценные пресеты
⭕ Про забытые поля напомнит линтер в CI, но решение всё равно за человеком
⏺ Каждый компонент нужно явно декларировать вместе со всеми параметрами. Когда добавляется новый параметр, то надо провести анализ, какое ему значение надо поставить или поставить Ignore
⏺ Разметка для песочницы живёт в проде, рядом с боевым кодом компонента

Ну и получается, что если в Android подход больше про "магию", то в iOS — больше про "контроль". Не знаю, хорошо или плохо это... Ответ мы еще не нашли

А что думаете вы? Какой метод показался более логичным и надежным? Делитесь мыслями ⬛