Да вот практика показала, что ничего страшного в этом нет. Раньше рассуждал так же, как и вы.
1. если вы работаете в команде, то все будут работать в одном огромном файле, что плохо скажется на сливании и комитах.
Конфликт при мердже будет конфликтом вне зависимости от того, в каком файле он произойдет.
2. если вам нужно внести правки в код, то не придется скролить в 2600 строке. Достаточно набрать в IDE имя нужного файла.
Аналогично вбиваете имя класса и перескакиваете к нему, при этом не нужно прыгать в панель файлов проекта.
3. нет структуры кода, невозможно понять какой класс/функция какому модулю принадлежат.
По-моему это немного не в тему. Мы ведь не про структурирование на модули говорим, а про то, как писать компоненты вгутри одного.
Давайте я закрою этот вопрос. Я лично пробовал делать обоими способами. Причем изначально был сторонником вашей позиции. И существенной разницы не почувствовал. Меня смутил безаппеляционный тон, поэтому я захотел услышать аргументы. Аргументы оказались чисто субъективными и объективных причин говорить, как «следует» делать, я так и не увидел.
Спасибо, буду признателен и, думаю, люди тоже, если вы поделитесь своими тасками =) Еще такой вопрос — как при такой системе подключаются сторонние библиотеки?
Иногда мне кажется, что, главным образом, в том, что angular получил серьезную пиар поддержку на старте. Сайты успешно делают и на том, и на другом. Каждый выбирает либо то, чем он лучше владеет, либо если не владеет ни тем, ни другим, то, о чем больше всего говорят. Сейчас мне кажется, что в Angular более четкая логика разделения модуля на контроллеры, сервисы и директивы, но не исключаю, что это только потому, что все последние проекты я делал на Angular, а не Knockout
А в чем фишка yoman? Просто в свое время, когда я для каждого контроллера, сервиса и т.д. создавал отдельный файл, мне было достаточно шаблонов в Webstorm для соответствующих элементов. Я правильно понимаю, что по функционалу это тоже самое?
преобразуется соответственно из habra-habr, habra:habr и т.д.
Обязательно расскажу про нормализацию атрибутов и форматы задания директив в заключительной части. Опустил это вначале из тех соображений, что это вопросы скорее относятся к стилю оформления кода, а не к самой концепции директив, и в самом начале особой пользы для понимания в них я не увидел.
Написать строчку комментария про $watch. Для новичков же статья
Да, тоже хотелось уйти от этого, но лучшей альтернативы для того, чтобы показать, как можно при инициализации директивы передавать в нее имя переменной в scope контролера и использовать ее, я не придумал.
Непонятно, зачем писать «внутри директивы interpolate "{{}}"», если проще написать: внутри выражения "{{}}"
Хотел акцентировать внимание на том, что все «выражения», которые пишутся в разметке есть директивы. Возможно слишком назойливо.
Почему второй пример записывается так:
compile: function compile(templateElement, templateAttrs) { templateElement.html("{{"+templateAttrs.habraHabrWork+"}}"+templateAttrs.habra+""); return function (scope, element, attrs) { } }
а не так, в соответствии с приведенным выше расширенным описанием директивы
compile: function compile(temaplateElement, templateAttrs) { templateElement.html("{{"+templateAttrs.habraHabrWork+"}}"+templateAttrs.habra+""); }, link: function (scope, element, attrs) { }
Да, конечно, если говорить про визуальные эффекты, то jQuery среди библиотек я пока что не вижу альтернативы. Тем более что базовые операции с DOM в Angular заимствованы у jQuery. Речь шла о валидации, да.
Конфликт при мердже будет конфликтом вне зависимости от того, в каком файле он произойдет.
Аналогично вбиваете имя класса и перескакиваете к нему, при этом не нужно прыгать в панель файлов проекта.
По-моему это немного не в тему. Мы ведь не про структурирование на модули говорим, а про то, как писать компоненты вгутри одного.
Давайте я закрою этот вопрос. Я лично пробовал делать обоими способами. Причем изначально был сторонником вашей позиции. И существенной разницы не почувствовал. Меня смутил безаппеляционный тон, поэтому я захотел услышать аргументы. Аргументы оказались чисто субъективными и объективных причин говорить, как «следует» делать, я так и не увидел.
Так не стесняйтесь же, поделитесь.
А про тестирование — тут каждый по-своему решает, хотя, конечно, можно и протрактор предложить.
-Pidora ответ.
Обязательно расскажу про нормализацию атрибутов и форматы задания директив в заключительной части. Опустил это вначале из тех соображений, что это вопросы скорее относятся к стилю оформления кода, а не к самой концепции директив, и в самом начале особой пользы для понимания в них я не увидел.
Да, тоже хотелось уйти от этого, но лучшей альтернативы для того, чтобы показать, как можно при инициализации директивы передавать в нее имя переменной в scope контролера и использовать ее, я не придумал.
Хотел акцентировать внимание на том, что все «выражения», которые пишутся в разметке есть директивы. Возможно слишком назойливо.
Согласен, внес изменения.