АА
да и в проде можно юзать на старых иос
Size: a a a
2019 June 06
АА
збс пообщался
S
инициализатор проставляет параметры всех внутренних вьюх, гораздо удобнее на мой взгляд делать это отдельно от лейаута и переиспользуемость повышается
АА
какая переиспользуемость? ты переиспользуешь там что-то?
АА
ну и конструктор с 5 параметрами как раз в лайауте
АА
глазами тебе постоянно надо туда-сюда прыгать чтобы понять че и как будет
АА
А в том году тоже с 24h delay выкладывали сессии?
По ощущениям чуть ли не сразу после трансляции
SS
за счет того что у тебя один метод для декларативного описания всего UI (лайаут, параметры вьюх, иерархия)
Что значит «декларативное описание»?....хм, разве в дисплейкит оно не декларативное ?
SS
имхо удобнее чем вызывать конструкторы с 5-6 параметрами
Так а если вьюхи надо настраивать, все равно эти 5-6 параметров надо будет куда то девать
АА
Так а если вьюхи надо настраивать, все равно эти 5-6 параметров надо будет куда то девать
А если не надо, то зачем мне их писать?
SS
Вероятно там можно не писать :)
SS
Вообще я использовал сториборды, и проблемы сильные были только «медленно рендерится когда громоздкий» и «мерджинг»
АА
Что значит «декларативное описание»?....хм, разве в дисплейкит оно не декларативное ?
Я писал про 1 метод для всего описания, именно это преимущество, асдк тоже в какой-то мере декларативный, но для свифта апи стремное
АА
Вообще я использовал сториборды, и проблемы сильные были только «медленно рендерится когда громоздкий» и «мерджинг»
Каждый раз боль при работе с этой хренью
АА
Примеры из книжек хорошо ложатся, а чуть сложнее уже боль
SS
Возможно SwiftUI это «свой display kit и свой RX вместе, плюс пара плюшек»....но я честно не смотрел его подробно
Так то классно, я просто против определений, «революция в разработке» и «надо только так»....хотя возможно это мне такие мнения мерещатся :)
Так то классно, я просто против определений, «революция в разработке» и «надо только так»....хотя возможно это мне такие мнения мерещатся :)
АА
Возможно SwiftUI это «свой display kit и свой RX вместе, плюс пара плюшек»....но я честно не смотрел его подробно
Так то классно, я просто против определений, «революция в разработке» и «надо только так»....хотя возможно это мне такие мнения мерещатся :)
Так то классно, я просто против определений, «революция в разработке» и «надо только так»....хотя возможно это мне такие мнения мерещатся :)
Больше радует изменения Свифта для того чтобы SwiftUI стал возможным. Много возможностей открывается теперь
V
Вообще я использовал сториборды, и проблемы сильные были только «медленно рендерится когда громоздкий» и «мерджинг»
1 экран – 1 сториборд. Вообще, не проблем
SS
Примеры из книжек хорошо ложатся, а чуть сложнее уже боль
Хм, почему?
(Я и в коде делал ui и люблю не меньше, но преимущества кода защищать бессмысленно наверное, и так все в курсе :) ) поэтому позащищаю SB :)
По-моему там наоборот удобнее делать много констрейнтов с приоритетами и разницей для sizeClass
К тому же если надо «подвинуть эту кнопку» то ясно сразу какую, а в коде не сразу ясно как называется favoriteButton markButton, (buttonWithStar ((( ), или какая то панель topPanel, controlPanel, actionsPanel....
Конечно в код можно вникнуть, но и в sb можно
Вероятно что в плохой код вникнуть проще и переделать частично чем в плохой sb
(Я и в коде делал ui и люблю не меньше, но преимущества кода защищать бессмысленно наверное, и так все в курсе :) ) поэтому позащищаю SB :)
По-моему там наоборот удобнее делать много констрейнтов с приоритетами и разницей для sizeClass
К тому же если надо «подвинуть эту кнопку» то ясно сразу какую, а в коде не сразу ясно как называется favoriteButton markButton, (buttonWithStar ((( ), или какая то панель topPanel, controlPanel, actionsPanel....
Конечно в код можно вникнуть, но и в sb можно
Вероятно что в плохой код вникнуть проще и переделать частично чем в плохой sb
В
Хм, почему?
(Я и в коде делал ui и люблю не меньше, но преимущества кода защищать бессмысленно наверное, и так все в курсе :) ) поэтому позащищаю SB :)
По-моему там наоборот удобнее делать много констрейнтов с приоритетами и разницей для sizeClass
К тому же если надо «подвинуть эту кнопку» то ясно сразу какую, а в коде не сразу ясно как называется favoriteButton markButton, (buttonWithStar ((( ), или какая то панель topPanel, controlPanel, actionsPanel....
Конечно в код можно вникнуть, но и в sb можно
Вероятно что в плохой код вникнуть проще и переделать частично чем в плохой sb
(Я и в коде делал ui и люблю не меньше, но преимущества кода защищать бессмысленно наверное, и так все в курсе :) ) поэтому позащищаю SB :)
По-моему там наоборот удобнее делать много констрейнтов с приоритетами и разницей для sizeClass
К тому же если надо «подвинуть эту кнопку» то ясно сразу какую, а в коде не сразу ясно как называется favoriteButton markButton, (buttonWithStar ((( ), или какая то панель topPanel, controlPanel, actionsPanel....
Конечно в код можно вникнуть, но и в sb можно
Вероятно что в плохой код вникнуть проще и переделать частично чем в плохой sb
по делу, поддерживаю