Я не считаю, что все эти задачи типа проверки авторизации и прочего должны быть частью кнопки лайк. Все эти задачи вообще не обязаны быть частью интерфейсного элемента. Они могут быть нужны когда-угодно, и как их достать из этого вайпера кнопки потом?
А экраном никто не должен управлять целиком, особенно если экран сложный. Надо разделять экран на несколько VC, делать делегаты-обработчики, которые не знают про существование экрана, а просто описывают логику, и так далее. В данном случае просто назначьте обработчик делегатом кнопки, но обработчик будет не классом, а тайпалиасом, который будет можно применить и к другим кнопкам с другими дженерик-параметрами.
А Вам не кажется, что вайпер на одну кнопку – это слишком много? Разве не логичнее делить кнопку не на шаблонные компоненты, а на аспекты кнопки – стиль там, способ нажатия, состояния?
Визуальный стиль может быть любой. Но если кнопка размером 1x1 пиксель, шрифт нечитаемый или работа программы блокируется многочисленными всплывающими окнами — программу могут отклонить.
Так и есть, но проверяют они это вручную.
В полуавтоматическом режиме можно проверить, наверное, только отсутствие вызовов к внутренним методам (использование закрытого API).
В том и прелесть правил Apple, что они очень гибкие. Проверить автоматически можно лишь немногие пункты, а в основном это больше вопрос интуитивного восприятия.
Честно говоря, всегда удивляла эта архитектура. Несмотря на формальную слабую связанность, фактически в большинстве случаев все элементы связаны сильно, потому что протоколы не переиспользуются для других экранов. Вообще ни один компонент не переиспользуется.
То есть вместо того, чтобы делегировать составляющие контроллера его компонентам и потом их переиспользовать (повторяющиеся анимации, действия, стили, логику работы и отображения), происходит не разделение, а расслоение контроллера, где каждый слой все равно уникален.
При этом такой подход и такое количество файлов убивает желание заниматься настоящей, разделяющей, декомпозицией.
Здесь же наблюдаем именно такую ситуацию. В SwiftUI реактивность является одной из основных идей фреймворка. Абстрагирование реактивности в пользу ручного управления состоянием должно иметь веские причины. Здесь же основная причина – противоречие канонам спорной, по моему мнению, архитектуры.
Как по мне, вред от бесплатного плана – это еще и вред от неиспользуемых функций. То есть возможности, имплементация в поддержка которых занимает 90% времени разработки, оказывается нужны нескольким процентам, их не включают в базовую подписку и пользователи даже не думают о них, а ведь деньги вложены. То есть у каждой возможности должна быть строгая мотивация, а не просто “Ну это же логично” и “Чтобы было”.
Если идет речь про крупных корпоративных клиентов, там уже идет более персонализированный допил, насколько я понимаю.
После F# остались только негативные эмоции. Размытый неконсистентный синтаксис, неуклюжий компилятор, миллион операторов, которые никто не подсказывает, язык постоянно лезет не в свое дело. Одно отсутствие циклического импорта чего стоит.
После Swift язык ощущается как ужасный самопал. В Swift для тех же Option придумали if case, if let, guard let, switch, optional chaining, optional init, implicitly unwrapped, все чтобы помочь программисту. В F#, насколько я понял, это только switch, который раздувает код. При этом в Swift value type это правда value type, а тут кто-то вернул из .NET record и пробуй обработать null, тебе пишут, что record не может быть null, ну да ну да. В Swift такие вещи маппятся в optional и никаких вопросов.
Или те же коллекции, которые не ведут себя как в .NET. Ну сделайте свой пакет коллекций, в чем проблема-то? Везде одни проблемы с этим языком.
Меня в вебе смущает не его масштабность, а то, что при всей это масштабности самые простые вещи сделаны такими сложными. Есть миллион способов сделать все, что угодно, только не то, что тебе нужно.
Я давно уже привык к мысли, что невозможно создать идеальный сложный сайт, за счет багов может сломаться отображение и у Google, и у Apple. Где хорошая инкапсуляция, которая позволит создавать переиспользуемые компоненты? Где нормальные блоки для скроллинга, которые будут вести себя корректно на разных браузерах (сейчас только основное окно является на 100% безопасным для имплементации скролла). Где таблицы с автозагрузкой компонентов вроде UITableView и UICollectionView в iOS? Почему анимации сделаны так неуклюже? Почему нельзя создать блок, где картинка по высоте будет равна соседнему блоку (рабочие решения только для хрома есть).
Почему даже для кастомного чекбокса надо проворачивать трюк из нулевых, а если есть какой-то полезный API, то наверняка он не поддерживается на одном из основных браузеров?
Да и "лучшие практики" веб-разработки – это просто какое-то метание из стороны в сторону. То зажатый и строго регламентированный AMP-сайт, то мегабайты JS в Flutter Web (и все от одного разработчика!). Как вообще идея с SPA прижилась в том же мире, где Google продвигает AMP? Почему для текстовых страниц необходимо грузить и выполнять столько CSS и JS?
Хотя может быть, на все эти вопросы и есть простые ответы, а я, как не веб-разработчик, просто их не нашел...
Ну, эта ситуация постепенно меняется. Большое количество разработчиков на маке (не только iOS) – ситуация сравнительно недавняя, например. Сама Apple заявляет, что 50% покупателей Mac – это люди, которые переходят с других ОС (правда не знаю, как они смогли собрать такую статистику).
Особенно заметен процесс по рынку США, где Apple набрала за год 5%. https://gs.statcounter.com/os-market-share/desktop/united-states-of-america
Конечно, вряд ли кто согласится с моим мнением, но кажется мне, что Google выдохся. Довольно неожиданно так говорить про компанию, которая везде и всюду, но просто подумайте – что они сделали нового за последние 10 лет? Все их ключевые программы и сервисы (поисковик, Gmail, Android, Chrome, Youtube, Карты) были сделаны уже более 10 лет назад. Ни одного реально нового пользовательского продукта за это время, только итеративное улучшение уже существующих. И при всем при этом, я постоянно нахожу самые разные баги во всех их приложениях. Даже удивительно, раз их создают так тщательно отобранные разработчики.
Не из-за этой ли системы отбора такая ситуация?..
Может, я и не прав, не спорю, но мое мнение – SwiftUI не взлетит.
UIKit разрабатывался очень гибким, пусть это и урезанная версия AppKit. SwiftUI не позволяет адекватно кастомизировать даже стандартные компоненты. Почему же на таком расчудесном фреймворке так сложно написать стандартные кнопки и текстовые поля?
полтора года прошло, а он все еще в подвешенном состоянии. Все же за это время такая компания, как Apple, могла бы привести его в адекватное состояние, чего не происходит.
есть сомнения в правильности концепции как таковой. Мне лично AutoLayout намного ближе и логичнее, чем некий урезанный аналог HTML/CSS. Да и UIKit сложный только для небольших проектов, чем проект сложнее, тем более оправдана комплексность этого фреймворка (и тем меньше она заметна на масштабе).
Но, наверное, главный аргумент состоит в том, что Apple в принципе мало вкладывается в разработку инструментов для разработки. XCode как был глючным, так и остался, Swift как был приколочен гвоздями к экосистеме Apple и Objective-C рантайму, так в принципе и остался. Вряд ли что-то изменится, поскольку на данный момент Apple просто не собирается серьезно инвестировать в упрощение разработки…
Вот никак не пойму, почему многим нравятся синтаксисы без скобок. Как по мне, это очень усложняет язык:
перенос кода ломает табуляцию;
выровнять код автоматически невозможно, поскольку табуляция имеет смысл;
дебажить куда труднее, кроме проблем с табуляцией появляются проблемы из-за размытости синтаксиса. Как в том же хаскеле, где забытый аргумент функции = проблема с типами, как и практически любая другая ошибка.
нотация через точку дает возможность легко просмотреть API объектов и классов, в языках без этого приходится каждый раз обращаться к документации;
А какие преимущества? Пара сэкономленных символов и некое эстетичное удовлетворение?
Джейлбрейк официально так и не смогли запретить. Есть актуальный на iOS 13. Да, нужна учетка разработчика вроде как для того, чтобы раз в 2 недели не прошиваться, но доступ к такой учетке стоит копейки.
Все-таки жаль, что не внедряют типы по примеру Swift'овского Type!, что дает обнуляемую ссылку, которую не надо каждый раз проверять. Это очень удобно когда значение null не имеет какой-либо семантики, но при этом необнуляемый тип не подходит по той или иной причине.
Мне кажется, тут Вы путаете свободу и вседозволенность. Как раз таки вседозволенность одной стороны приводит к несвободе другой. В обоих случаях, которые ВЫ тут указали, имеется именно случай вседозволенности. Просто в одном уполномочили оператора, которому Вы не доверяете, в другому – государство, к которому у Вас есть доверие (на каких основаниях?).
Свобода – это право выбора. Можете доверять оператору, можете государству. И доверяете кому-то не потому, что у него имеются определенные заложенные по архитектуре привилегии, а потому, что конкретно в этом аспекте он лучше. Например, дает возможность отслеживать, какие данные были собраны и кому они были доставлены. Дает возможность отключить какие-то аспекты отслеживания. А если что-то не нравится, то можно создать еще одного оператора, и если будет соблюдение открытых стандартов, до него даже смогут дозвониться.
Меня всегда удивляло, как можно в свободном сообществе пропагандировать что-то огороженное, не имеющие ни открытых стандартов, ни прозрачности.
Ведь в Вашем «идеальном мире» Вы бы не смогли продвигать противоположную точку зрения…
Сделали бы техническое сравнение – другое дело.
Мне всегда, когда я начинаю проект, хочется писать красивый код. Но когда пробую написать красивый CSS, это оказывается просто невозможно. Да, в каких-то частных случаях, описанный подход будет работать. Но вот попадает в руки реальный макет…
Каждый элемент со своими параметрами, что они в переменных, что не в переменных, все равно они жестко привязаны друг к другу и будут встречаться один раз. А следовать макету нужно, Pixel Perfect и все такое.
Хочется задать зависимости явно, но сделать это как правило невозможно. Если изначально доступны параметры размера – хорошо, а если нет? Если это текстовый блок произвольной длины? А если все параметры меняются за счет адаптивности?
Выделить несколько ключевых цветов – хорошо, но их будет в макете явно не один и не два, а потом возникнет ситуация, когда часть компонентов надо будет сделать еще другим цветом и все равно придется править все вручную. Так какая разница в таком случае, править вручную названия переменных или конкретных цвета?
Часто понимаешь, что повторяешь одни и те же действия, но как от этого уйти? Нету никакой возможности создать переиспользуемые инкапсулированные компоненты. Всегда найдется вариант внешней разметки, при которой внутренняя разметка компонента сломается. Мы не знаем, чего захочет клиент такой библиотеки, какой модификации. При использовании любой готовой библиотеки довольно быстро возникает ситуация, когда возможностей не хватает и приходится писать все самостоятельно.
Что касается CSS-in-JS, то с таким подходом, как правило, получаются сайты, плохо работающие в относительно старых браузерах, чего только стоит JS-скролл. Кроме того, JS-код не владеет объектами на странице, а является лишь довеском к документу, со слабой сетью может и не загрузиться. Никогда не хочется пользоваться сайтом, на котором подача статической информации зависит от JS.
Вообще, хотелось бы видеть примеры хорошей абстрактной разметки на рабочих проектах, сделанных по макету. Потому что когда сталкиваешься со всеми этими проблемами, просто руки опускаются что-то делать красиво.
А можете пояснить, бывает ли соответствие Action и Reducer не 1 к 1? Если нет, то какой смысл разделения этих слоёв?
Я не считаю, что все эти задачи типа проверки авторизации и прочего должны быть частью кнопки лайк. Все эти задачи вообще не обязаны быть частью интерфейсного элемента. Они могут быть нужны когда-угодно, и как их достать из этого вайпера кнопки потом?
А экраном никто не должен управлять целиком, особенно если экран сложный. Надо разделять экран на несколько VC, делать делегаты-обработчики, которые не знают про существование экрана, а просто описывают логику, и так далее. В данном случае просто назначьте обработчик делегатом кнопки, но обработчик будет не классом, а тайпалиасом, который будет можно применить и к другим кнопкам с другими дженерик-параметрами.
А Вам не кажется, что вайпер на одну кнопку – это слишком много? Разве не логичнее делить кнопку не на шаблонные компоненты, а на аспекты кнопки – стиль там, способ нажатия, состояния?
Визуальный стиль может быть любой. Но если кнопка размером 1x1 пиксель, шрифт нечитаемый или работа программы блокируется многочисленными всплывающими окнами — программу могут отклонить.
Так и есть, но проверяют они это вручную.
В полуавтоматическом режиме можно проверить, наверное, только отсутствие вызовов к внутренним методам (использование закрытого API).
В том и прелесть правил Apple, что они очень гибкие. Проверить автоматически можно лишь немногие пункты, а в основном это больше вопрос интуитивного восприятия.
Честно говоря, всегда удивляла эта архитектура. Несмотря на формальную слабую связанность, фактически в большинстве случаев все элементы связаны сильно, потому что протоколы не переиспользуются для других экранов. Вообще ни один компонент не переиспользуется.
То есть вместо того, чтобы делегировать составляющие контроллера его компонентам и потом их переиспользовать (повторяющиеся анимации, действия, стили, логику работы и отображения), происходит не разделение, а расслоение контроллера, где каждый слой все равно уникален.
При этом такой подход и такое количество файлов убивает желание заниматься настоящей, разделяющей, декомпозицией.
Здесь же наблюдаем именно такую ситуацию. В SwiftUI реактивность является одной из основных идей фреймворка. Абстрагирование реактивности в пользу ручного управления состоянием должно иметь веские причины. Здесь же основная причина – противоречие канонам спорной, по моему мнению, архитектуры.
Как по мне, вред от бесплатного плана – это еще и вред от неиспользуемых функций. То есть возможности, имплементация в поддержка которых занимает 90% времени разработки, оказывается нужны нескольким процентам, их не включают в базовую подписку и пользователи даже не думают о них, а ведь деньги вложены. То есть у каждой возможности должна быть строгая мотивация, а не просто “Ну это же логично” и “Чтобы было”.
Если идет речь про крупных корпоративных клиентов, там уже идет более персонализированный допил, насколько я понимаю.
После F# остались только негативные эмоции. Размытый неконсистентный синтаксис, неуклюжий компилятор, миллион операторов, которые никто не подсказывает, язык постоянно лезет не в свое дело. Одно отсутствие циклического импорта чего стоит.
После Swift язык ощущается как ужасный самопал. В Swift для тех же Option придумали if case, if let, guard let, switch, optional chaining, optional init, implicitly unwrapped, все чтобы помочь программисту. В F#, насколько я понял, это только switch, который раздувает код. При этом в Swift value type это правда value type, а тут кто-то вернул из .NET record и пробуй обработать null, тебе пишут, что record не может быть null, ну да ну да. В Swift такие вещи маппятся в optional и никаких вопросов.
Или те же коллекции, которые не ведут себя как в .NET. Ну сделайте свой пакет коллекций, в чем проблема-то? Везде одни проблемы с этим языком.
Меня в вебе смущает не его масштабность, а то, что при всей это масштабности самые простые вещи сделаны такими сложными. Есть миллион способов сделать все, что угодно, только не то, что тебе нужно.
Я давно уже привык к мысли, что невозможно создать идеальный сложный сайт, за счет багов может сломаться отображение и у Google, и у Apple. Где хорошая инкапсуляция, которая позволит создавать переиспользуемые компоненты? Где нормальные блоки для скроллинга, которые будут вести себя корректно на разных браузерах (сейчас только основное окно является на 100% безопасным для имплементации скролла). Где таблицы с автозагрузкой компонентов вроде UITableView и UICollectionView в iOS? Почему анимации сделаны так неуклюже? Почему нельзя создать блок, где картинка по высоте будет равна соседнему блоку (рабочие решения только для хрома есть).
Почему даже для кастомного чекбокса надо проворачивать трюк из нулевых, а если есть какой-то полезный API, то наверняка он не поддерживается на одном из основных браузеров?
Да и "лучшие практики" веб-разработки – это просто какое-то метание из стороны в сторону. То зажатый и строго регламентированный AMP-сайт, то мегабайты JS в Flutter Web (и все от одного разработчика!). Как вообще идея с SPA прижилась в том же мире, где Google продвигает AMP? Почему для текстовых страниц необходимо грузить и выполнять столько CSS и JS?
Хотя может быть, на все эти вопросы и есть простые ответы, а я, как не веб-разработчик, просто их не нашел...
А в чем, собственно, была проблема?
Почему JS браузеры безопасно выполняют, а плеер Flash не мог?
Ну, эта ситуация постепенно меняется. Большое количество разработчиков на маке (не только iOS) – ситуация сравнительно недавняя, например. Сама Apple заявляет, что 50% покупателей Mac – это люди, которые переходят с других ОС (правда не знаю, как они смогли собрать такую статистику).
Особенно заметен процесс по рынку США, где Apple набрала за год 5%. https://gs.statcounter.com/os-market-share/desktop/united-states-of-america
Конечно, вряд ли кто согласится с моим мнением, но кажется мне, что Google выдохся. Довольно неожиданно так говорить про компанию, которая везде и всюду, но просто подумайте – что они сделали нового за последние 10 лет? Все их ключевые программы и сервисы (поисковик, Gmail, Android, Chrome, Youtube, Карты) были сделаны уже более 10 лет назад. Ни одного реально нового пользовательского продукта за это время, только итеративное улучшение уже существующих. И при всем при этом, я постоянно нахожу самые разные баги во всех их приложениях. Даже удивительно, раз их создают так тщательно отобранные разработчики.
Не из-за этой ли системы отбора такая ситуация?..
Может, я и не прав, не спорю, но мое мнение – SwiftUI не взлетит.
Но, наверное, главный аргумент состоит в том, что Apple в принципе мало вкладывается в разработку инструментов для разработки. XCode как был глючным, так и остался, Swift как был приколочен гвоздями к экосистеме Apple и Objective-C рантайму, так в принципе и остался. Вряд ли что-то изменится, поскольку на данный момент Apple просто не собирается серьезно инвестировать в упрощение разработки…
Вот никак не пойму, почему многим нравятся синтаксисы без скобок. Как по мне, это очень усложняет язык:
А какие преимущества? Пара сэкономленных символов и некое эстетичное удовлетворение?
Свобода – это право выбора. Можете доверять оператору, можете государству. И доверяете кому-то не потому, что у него имеются определенные заложенные по архитектуре привилегии, а потому, что конкретно в этом аспекте он лучше. Например, дает возможность отслеживать, какие данные были собраны и кому они были доставлены. Дает возможность отключить какие-то аспекты отслеживания. А если что-то не нравится, то можно создать еще одного оператора, и если будет соблюдение открытых стандартов, до него даже смогут дозвониться.
Ведь в Вашем «идеальном мире» Вы бы не смогли продвигать противоположную точку зрения…
Сделали бы техническое сравнение – другое дело.
Каждый элемент со своими параметрами, что они в переменных, что не в переменных, все равно они жестко привязаны друг к другу и будут встречаться один раз. А следовать макету нужно, Pixel Perfect и все такое.
Хочется задать зависимости явно, но сделать это как правило невозможно. Если изначально доступны параметры размера – хорошо, а если нет? Если это текстовый блок произвольной длины? А если все параметры меняются за счет адаптивности?
Выделить несколько ключевых цветов – хорошо, но их будет в макете явно не один и не два, а потом возникнет ситуация, когда часть компонентов надо будет сделать еще другим цветом и все равно придется править все вручную. Так какая разница в таком случае, править вручную названия переменных или конкретных цвета?
Часто понимаешь, что повторяешь одни и те же действия, но как от этого уйти? Нету никакой возможности создать переиспользуемые инкапсулированные компоненты. Всегда найдется вариант внешней разметки, при которой внутренняя разметка компонента сломается. Мы не знаем, чего захочет клиент такой библиотеки, какой модификации. При использовании любой готовой библиотеки довольно быстро возникает ситуация, когда возможностей не хватает и приходится писать все самостоятельно.
Что касается CSS-in-JS, то с таким подходом, как правило, получаются сайты, плохо работающие в относительно старых браузерах, чего только стоит JS-скролл. Кроме того, JS-код не владеет объектами на странице, а является лишь довеском к документу, со слабой сетью может и не загрузиться. Никогда не хочется пользоваться сайтом, на котором подача статической информации зависит от JS.
Вообще, хотелось бы видеть примеры хорошей абстрактной разметки на рабочих проектах, сделанных по макету. Потому что когда сталкиваешься со всеми этими проблемами, просто руки опускаются что-то делать красиво.