Comments 15
Очень близкий механизм использует typescript для поддержки tsx синтаксиса. Только там кроме билдеров нужно еще и информацию о типах нод объявлять для автокомплита внутри tsx контекста. Странно что этот proposal нигде не упоминает ее. Обычно в swift evaluation везде указывают существующие решения в других языках/платформах.
На мой вкус реализация в typescript чуть функциональнее для пользователя API. Если кому интересно, то я писал о ней на хабре.
Мне эти танцы с бубнами напомнили внедрение HTML 5 в web.
и первые пробы WPF и его XAML разметки.
Всё новое это хорошо забытое старое, не волнуйтесь, года через 3 пройдет и этот UI все детские ошибки и станет юзабелен с точки зрения логики в том числе. А через 5 либо умрет либо станет стандартом.
Ирония в том что через 3 года появится какой-нибудь новый язык для разметки UI для iOS и тысячи людей будут снова проходить всё это.
У Flutter от гугла сейчас такие же истории встречаю.
Я например очень рад что MS вдохнули вторую жизнь в этом году в WPF/UWP и сторонние фреймворки (вроде авалонии) использующие XAML разметку. Уж больно не охота изучать каждые 3-4 года новые сырые способы разметки, когда старый добрый XAML на порядки сильнее, да и ты в нём профи. Но наличие конкуренции это стимул, это важно. Иначе выйдет как с html 5 в котором вроде бы как есть верстка на Grid и всеми поддерживается, но ее никто не использует, «верстаем на div с 2003-го»
Чего стоят такие пример как кубы с формами и все это можно встраивать друг в друга
— XAML islands — мосты между UWP и WPF/winform проектами позволяющие использовать компоненты одной платформы в другой.
— анонсированное объединение всех фреймворков в .net 5 который полностью кросплатформ.
Ну и по мелочи всяческими плюшками присыпали это все сверху.
Я не знаю swift, но такое чувство, что еще чуть-чуть и они заново изобретут С++11 :D
Подождите-ка, а зачем там variadic generics?
Билдер же по сути должен принять массив UIView, апкаст же неявен насколько я помню.
Текущий ViewBuilder принимает на вход generic аргументы, с одним ограничением: каждый из них должен реализовывать протокол View.
static func buildBlock<C0, C1, C2>(_ c0: C0, _ c1: C1, _ c2: C2) -> TupleView<(C0, C1, C2)> where C0 : View, C1 : View, C2 : ViewПри этом аргументы могут быть совершенно разного типа. Например в VSack мы можем положить TextField, Toggle и что-нибудь еще вместе. И я думаю под капотом недостаточно знать, что аргумент под протоколом View — важно знать конкретный тип каждого аргумента.
Так TextField и Toogle как раз таки это View в общем-то.
Тут разве что есть специфичная обработка для каких-то типов, но это можно и в рантайме сделать тогда(хотя не припомню у стека ничего такого).
В общем, для меня такой билдер выглядит странно.
ViewBuilder, а в протоколе View, который имеет один ассоциированный тип для body, а значит его нельзя положить в коллекцию без заворачивания в AnyView. Вместо коллекции используется кортеж завернутый в TupleView. Кортежи не поддерживают переменное количество аргументов, отсюда необходимость набора методов buildBlock() с определенным количеством дженерик аргументов.Остается вопрос — зачем вообще в
View ассоциированный тип? Официального ответа от Apple пока нет, но вот тут обсуждались некоторые возможные причины, среди которых главная — оптимизация производительности. ---мимо---
Магия SwiftUI или о Function builders