AVKor: вот вы как пользователь debian системы скажите, вы разобрались с менеджерами пакетов? Если нет - тогда снимаю вопрос и тогда мои доводы действительно смешны.
AVKor: это конечно субъективная оценка, но я сомневаюсь что ТС использует debian в качестве своей "домашней" системы (судя по специфике вопроса). А стало быть это какой-то сервак, куда автор хочет задеплоить свои поделки. А стало быть это "продекшен" (или стэйджинг, называйте как хотите).
Паша: по сути единственные чуваки. которым приходится работать с восьмеркой. это чуваки на win xp. А теперь давайте вспомним, win xp вышла в 2001-ом году. А сегодня уже 2016-ый.
Есть конечно определенные специфичные проекты, где это нужно, но их мало. А потому никто не будет придумывать отдельные дебаггеры и т.д. С большего эмуляция в ie11 покрывает большинство возможных багов, хотя конечно это не панацея.
Dave: ну вот давайте рассуждать. Требовать от джуниора понимание инкапсуляции нужно или нет? Или хватит того что бы определение заучил для собеса?
Не путайте джуниора и стажера. Разница между джуниором и синьером по сути будет только в том, что даже при имении понимания принципов SOLID у первого не с первой попытки будет получаться не нарушить случайно эти принципы, и придется чаще переделывать и чаще эксперементировать.
Это как "зачем джуниору уметь тесты писать". Именно из-за такого подхода большинство разработчиков так слабы и можно найти сотни "синьеров" которые ни разу не знают что такое технический долг.
С другой стороны за счет этого стоимость джуниора такая низкая, да. Потому что половина из них еще даже не джуниоры.
dk-web: $scope это viewmodel, оно не глобально, оно зависит от контекста. Но что более важно - это внутрянняя кухня ангуляра и нечего с ней работать напрямую.
dk-web: нет, я не про angular2. Angular 1.5 это эдакий промежуточный этап между 1.x и 2.0.
Для того что вы описали сойдет все что угодно, любая статья про двусторонний биндинг. Единственное что - старайтесь вообще не использовать $scope. Вот воообще. Меньше будет проблем. И старайтесь использовать директивы/компоненты, код будет лучше реюзаться. Но это уже можно сказать "уровень новичек+", так что можете сначала на своих задачах сосредоточиться.
Дмитрий: нет, вы просто тестируете ресолв (их можно использовть как сервисы), а контроллера самого стэйта нет вообще. Тестировать же то, что uiRouter правильно отработал смысла нет вообще, поскольку он и так тестами покрыт.
Дмитрий: нет, в рамках юнит тестов вы тестируете что-то одно. То есть вы в контроллерах должны мокать все зависимости.
А вообще задумайтесь над тем что бы:
1) не делать вообще ничего кроме как сэттинг зависимостей в конструкторе компонента/директивы. Для каких-то сложных вещей есть хуки.
2) попробуйте отказаться от получения данных внутри компонентов, делайте это в ресолвах роутера и прокидывайте через биндинги. Тогда тестировать будет намного проще.
Максим Тимофеев: ну вот взял и обидел. Мне вот xcode нужен, да и по железу у маков в его ценовой категории не особо много конкурентов (по комбинации всех ништяков, от экрана до времени работы) Да и между прочим я вообще докером на маке орудую.
copal: он не "скопирован" с react, идее web-компонентов уже лет так 7. Если вы пороетесь в ишус трекере ангуляра то путь на компонентный подход был избран еще в начале 2013-ого года, когда реакт еще не набрал такой дикой популярности. Да и различия между ангуляром и реактом весьма существенны - в каком месте происходит дерти чекинг.
> И дальше по стеку - не тратьте время на фраймворки, тратьте время на технологии.
ммм.... например? Это очень смутная рекомендация.
> так как есть технологии более новые на которых приятно писать.
sanex3339: справедливости ради - "хелперы" - плохое и ленивое имя, не говорит ничего. Можно же именовать как-то более красиво, "сортировка" например, "фильтры". Что бы обозначало что там лежит.
splincodewd: API это набор методов, а объект это, просто функции экспортируемые модулем - это уже мелочи. Объекты надо использовать тогда, когда мы хотим изолировать побочные эффекты (или хэндлить внутреннее состояние) или удобненько управлять зависимостями, хотя с этим и модули неплохо справляются, инверсию зависимостйе можно и ими организовать.
splincodewd: развиваться и учиться. Учить JS, читать умные книжки всяких фаулеров, кентов бэков и т.д. (то есть большая часть необходимых знаний вообще не привязана к языку программирования). Почитать что-нибудь на тему функционального программирования (о том что мутация состояния - это плохо, а в вашем коде много побочных эффектов из-за этого всплывает). Про ООП почитать. Ну и задавать вопросы и пытаться разбираться.
1) ну разберитесь с синтаксисом, это не объявление приватных свойств, это переменные. Ну и да, в js нет приватных свойств, инкапсуляция достигается там через модули.
2) да, исключения пагубно влияют на производительность, но в продакшен коде у вас не должно вообще возникать исключений (в идеале). Если исключения начинают влиять на производительность js кода - стало быть у вас где-то баг.
3) вопервых вы меняли сам массив, а массивы в js хранятся по ссылке, то есть можно было смело использовать const. Во вторых вместо мутации состояния (к слову забыл упомянуть что stateless всегда лучше stateful) можно было просто собрать новый массив. Да и опять же возвращаемся к пункту 1 - мы не умеем работать с объектами (свойства, методы, прототип объекта)
4) свойства вместо переменных.
5) в "стандартную сортировку" можно передать функцию сортировки, который реализует эти правила.
6) все названия функций и методов - camelCase, конструкторы объектов (ну или имена классов если мы про сахар над Object.create) - CamelCase.
7) он должен предоставлять состояние, а работать с document.write должен кто-нибудь другой. Если бы это были отдельные функции - все было бы хорошо (а это могли бы быть просто отдельные функции). А так у нас выходит объект с нарушением принципа единой ответственности.
8) от вас требовалось javascript api, а не класс. Это мог бы быть просто модуль предоставляющий одну единственную функцию или две функции.
