1) При изменении логики внутри запросов необходимо поправить только xml и не лезть в код (например, в больших командах будет меньше конфликтов в VCS между теми кто поправил код, исправив баг в бизнес логике, и теми кто внес правку в xml).
2) Сами xml могут быть получены извне приложения (да, такое иногда нужно).
Мне кажется у Вас небольшая проблема с исходными данными.
Судя по скриншоту у Вас почти одинаковые строчки в базе, а насколько мне помнится алгоритмы 7z и zip по умолчанию используют словарное сжатие, поэтому у вас со 198Мб порезалось до 3/10. Боюсь с реальными данными все не будет столь радужно…
И есть костыль: если у вас проблема с производительностью используйте одноразовый биндинг.
Вы, мне кажется, немного подменили понятия. Одноразовый биндинг он не для улучшения производительности был придуман (хотя безусловно одна из причин его возникновение это стремление улучшить Ангуляр в этом месте), а для усечения логики работы там, где двунаправленная связь не требуется.
Согласитесь, глупо следить за моделью, которая один раз загрузилась и больше не собирается меняться. Это архитектурно и логически неверно. Поэтому умные ребята сели, почесали репу и поняли что промазали при проектировании Ангуляра с этой фичей. Я, по крайней мерее, себе это так вижу.
Вообще, мне кажется, лучше было бы обращать внимание на другие более слабые места, типа неэффективной работы ng-repeat или отвратительной поддержки локализации, чем на односторонний биндинг и количество теоретически обрабатываемых вотчеров…
Я все равно в упор не пойму, почему односторонний биндинг это костыль?
Давайте монады окрестим костылем, потому что они были придуманы в т.ч. из-за проблем с читаемостью кода с тучей проверок, почему нет?
Один я не увидел обвинений в бесполезности?
Ребят, без обид кончено, опенсорс это очень круто и спасибо вам, но у вашей компании слегка завышено самомнение.
Итак, вдумаемся в происходящее.
Директива — компонент, который представляет собой переиспользуемый виджет или специфичный код для работы с DOM-деревом браузера и стилями.
У каждой директивы есть свой шаблон. Если возникает задача, которая не подпадает под ответственность этой директивы (например, в одном месте надо показывать связывание «two-way», в другом «one-way») у нас с Вами есть два пути:
Делаем новую директиву, если логика трансформируется настолько, что не может быть обслужена существующей директивой.
Делаем другой шаблон, удовлетворяющий нашей задаче и используем его в зависимости от некой логики (в контексте обсуждения неважно кем и где она будет задаваться, но чаще всего это внутренняя логика директивы)
Это дополнительный параметр, причем чем сложнее модель, тем больше таких дополнительных параметров. Это очень плохо.
Здесь я с Вами соглашусь, это есть плохо. Но при этом, Вас никто не заставляет так делать и есть куда лучшие микроархитектурные решения.
Не очень понял, что мы нарушаем. Данные как устанавливались, так и устанавливаются в одном месте. Решать отображать изменения или нет и в каком виде, это дело вью-модели и шаблона. Обычный MVVM паттерн.
Проблема тут, к сожалению, не техническая… Для подобного ресурсы нужны, деньги и много сил различных специалистов, чтобы просто хотя бы заявить о себе. Это уже бизнес, просто так в отпуск сделать не получится…
Спасибо за ссылку. Код минифицирован конечно, но выскажу предположение, что у Вас обилие биндинга, связанного с анимационными объектами (которые кстати в base64 лежат в скриптах).
Но это не отменяет проблемности самого Angular. Когда на одном фрэймворке трудно сделать хорошо, а на другом трудно сделать плохо, это какбе намекает.
Не отменяет, проблемы есть везде и разработчики или дают аргументированное объяснение почему было сделано так, а не иначе, или исправляют/планируют к исправлению проблему. Это, на мой взгляд, и отличает «хороший» инструмент от «плохого». Из-за таких вот проблем появилось одностороннее связывание и начали делать Angular 2.
Не соглашусь с фразами «трудно сделать хорошо» и «трудно сделать плохо», все зависит от задачи, исполнителя, бюджета и множества других факторов. Так можно сказать о любом инструменте.
А у Вас не остался этот проблемный проект, есть возможность показать? Мне очень интересно было бы взглянуть.
Просто часто читаю подобные вещи и все заканчивается одинаково — неверно спроектированное приложение, неправильное использование компонентов фреймворка, иногда неверное представление о работе и жизненном цикле, и как результат разочарование и решение проблемы — уход от проблемы и сопровождение гневными постами на хабре :)
Честно говоря Ваши аргументы не убедительны для меня пока.
Традиционно считается, что потолком для Angular являются 2000 watcher'ов.
Есть очень хороший и дельный ответ самих разработчиков на эту тему. Цитата:
What about performance?
So it may seem that we are slow, since dirty-checking is inefficient. This is where we need to look at real numbers rather than just have theoretical arguments, but first let's define some constraints.
Humans are:
Slow — Anything faster than 50 ms is imperceptible to humans and thus can be considered as «instant».
Limited — You can't really show more than about 2000 pieces of information to a human on a single page. Anything more than that is really bad UI, and humans can't process this anyway.
So the real question is this: How many comparisons can you do on a browser in 50 ms? This is a hard question to answer as many factors come into play, but here is a test case: jsperf.com/angularjs-digest/6 which creates 10,000 watchers. On a modern browser this takes just under 6 ms. On Internet Explorer 8 it takes about 40 ms. As you can see, this is not an issue even on slow browsers these days. There is a caveat: the comparisons need to be simple to fit into the time limit… Unfortunately it is way too easy to add a slow comparison into AngularJS, so it is easy to build slow applications when you don't know what you are doing. But we hope to have an answer by providing an instrumentation module, which would show you which are the slow comparisons.
Мне кажется, это отражает реальную суть вещей — если у Вас такое количество информации на странице и при этом все _постоянно_ меняется, то может стоит задуматься над изменением архитектуры фронтенда?
1) При изменении логики внутри запросов необходимо поправить только xml и не лезть в код (например, в больших командах будет меньше конфликтов в VCS между теми кто поправил код, исправив баг в бизнес логике, и теми кто внес правку в xml).
2) Сами xml могут быть получены извне приложения (да, такое иногда нужно).
А не пробовали другие алгоритмы сжатия использовать? Было бы интересно глянуть на результаты по сжатию различными алгоритмами.
Судя по скриншоту у Вас почти одинаковые строчки в базе, а насколько мне помнится алгоритмы 7z и zip по умолчанию используют словарное сжатие, поэтому у вас со 198Мб порезалось до 3/10. Боюсь с реальными данными все не будет столь радужно…
Тем не менее спасибо за статью.
Речь не о дублировании, а о создании шаблона/директивы удовлетворяющим задаче.
Вы, мне кажется, немного подменили понятия. Одноразовый биндинг он не для улучшения производительности был придуман (хотя безусловно одна из причин его возникновение это стремление улучшить Ангуляр в этом месте), а для усечения логики работы там, где двунаправленная связь не требуется.
Согласитесь, глупо следить за моделью, которая один раз загрузилась и больше не собирается меняться. Это архитектурно и логически неверно. Поэтому умные ребята сели, почесали репу и поняли что промазали при проектировании Ангуляра с этой фичей. Я, по крайней мерее, себе это так вижу.
Вообще, мне кажется, лучше было бы обращать внимание на другие более слабые места, типа неэффективной работы ng-repeat или отвратительной поддержки локализации, чем на односторонний биндинг и количество теоретически обрабатываемых вотчеров…
Давайте монады окрестим костылем, потому что они были придуманы в т.ч. из-за проблем с читаемостью кода с тучей проверок, почему нет?
Ребят, без обид кончено, опенсорс это очень круто и спасибо вам, но у вашей компании слегка завышено самомнение.
Директива — компонент, который представляет собой переиспользуемый виджет или специфичный код для работы с DOM-деревом браузера и стилями.
У каждой директивы есть свой шаблон. Если возникает задача, которая не подпадает под ответственность этой директивы (например, в одном месте надо показывать связывание «two-way», в другом «one-way») у нас с Вами есть два пути:
Здесь я с Вами соглашусь, это есть плохо. Но при этом, Вас никто не заставляет так делать и есть куда лучшие микроархитектурные решения.
Ну а про хрупкость вообще не понял.
Не знаю, что еще можно Вам написать. :)
Не отменяет, проблемы есть везде и разработчики или дают аргументированное объяснение почему было сделано так, а не иначе, или исправляют/планируют к исправлению проблему. Это, на мой взгляд, и отличает «хороший» инструмент от «плохого». Из-за таких вот проблем появилось одностороннее связывание и начали делать Angular 2.
Не соглашусь с фразами «трудно сделать хорошо» и «трудно сделать плохо», все зависит от задачи, исполнителя, бюджета и множества других факторов. Так можно сказать о любом инструменте.
Просто часто читаю подобные вещи и все заканчивается одинаково — неверно спроектированное приложение, неправильное использование компонентов фреймворка, иногда неверное представление о работе и жизненном цикле, и как результат разочарование и решение проблемы — уход от проблемы и сопровождение гневными постами на хабре :)
Честно говоря Ваши аргументы не убедительны для меня пока.
Есть очень хороший и дельный ответ самих разработчиков на эту тему. Цитата:
Мне кажется, это отражает реальную суть вещей — если у Вас такое количество информации на странице и при этом все _постоянно_ меняется, то может стоит задуматься над изменением архитектуры фронтенда?