Angular и семантическая разметка/разделение проблем

Возможно, это нехорошее место, чтобы спросить об этом, но я постараюсь сделать его максимально объективным и ответственным.

Я играю с Angular.js и очень люблю его, но у меня есть вопрос о его философии. Здесь приведен фрагмент кода с сайта Angular для контроллера.

   <div ng-controller="TodoCtrl">
      <span>{{remaining()}} of {{todos.length}} remaining</span>
      [ <a href="" ng-click="archive()">archive</a> ]
      <ul class="unstyled">
        <li ng-repeat="todo in todos">
          <input type="checkbox" ng-model="todo.done">
          <span class="done-{{todo.done}}">{{todo.text}}</span>
        </li>
      </ul>
      <form ng-submit="addTodo()">
        <input type="text" ng-model="todoText"  size="30"
               placeholder="add new todo here">
        <input class="btn-primary" type="submit" value="add">
      </form>
    </div>

Это, в основном, HTML с помощью опций Angular. Тот, который я нахожу потенциально susupect, таков: <a href="" ng-click="archive()">archive</a>.

Когда Джеффри Зельдман написал "Разработка веб-стандартов" , стало лучше всего разделить разметку (HTML), презентацию (CSS) и взаимодействие (JS) в разные файлы для удобства обслуживания.

Мой вопрос в том, как Angular не нарушает это? Я действительно наслаждаюсь этим и считаю его достаточно мощным, но в чем разница между привязкой события click к элементу a, подобному этому в разметке, и написанием этого остатка кода, предшествующего веб-стандартам:

<a href='#' onClick='showAlert()'>Click here</a>

<script>
    var showAlert = function(){
      alert('hey');
    }
</script>

Полезные ответы могут относиться к документации в дополнение к личному опыту использования фреймворка.

Ответы

Ответ 1

Я начну с фрагмента кода, который вы найдете подозрительным, и фундаментальное различие между тем, как он обрабатывается в AngularJS по сравнению с обычным HTML и Javascript.

Это в основном HTML с директивами Angular. что я нахожу потенциально susupect это: <a href="" ng-click="archive()">archive</a>.

Это выглядит ужасно похоже на то, что мы бы написали 10 лет назад:

<a href="" onclick="archive()">archive</a>

Однако существует принципиальное различие между вышеупомянутым HTML и реализацией AngularJS. Для AngularJS функция archive находится в области, которую мы контролируем и можем манипулировать с помощью контроллеров. Необработанный пример JS требует, чтобы archive находился в глобальном пространстве имен (что плохо по многим причинам).

Но мы все еще можем видеть, что означало привязку события onclick; это означало, что можно было декларативно построить поведение в представлении и позволить JS обрабатывать детали реализации. AngularJS делает это, И предоставляет способ организации разностных областей/контекстов нашего представления таким образом, который невозможен с помощью обычного HTML.

Да, AngularJS включает в себя расширение HTML, перемещая больше представлений и связанных проблем в представление. Хорошей новостью является то, что мы движемся с HTML6. Вот некоторые цитаты из http://html6spec.com/:

Представьте, что вы можете отметить что-то так, как вы хотите его пометить вверх. Представьте, что вы меняете <div id="wrapper"> на <wrapper>...

Интернет движется к гигантскому магазину приложений, и нам нужно его охватить. Разметка, которую мы используем, не должна работать против нас, она должна работать на нас. Эта спецификация должна сделать именно это. Чтобы окончательно вырваться из унылых правил и стандарты и предоставить нам, разработчикам, полную свободу кодирования, поскольку мы пожалуйста, принеся в сеть более семантическую, чистую и удобную для человека разметки.

В некотором смысле, AngularJS приносит нам всю доброту HTML6, но позволяет нам использовать его сегодня. То, как используется сеть, резко изменилось за последние 15 лет, и наши инструменты все еще сильно отстают. К счастью для нас, будущее является маяком света и надежды, а AngularJS возвращает будущее к настоящему.

Ответ 2

Довольно интересное наблюдение и вопрос, и хороший ответ от @mortalapeman.

Я хотел бы добавить, что функция html, и наши ожидания того, что она должна делать, меняются. Нам научили полностью исключать наше поведение из документа (html) и, скорее, настроить наш код, чтобы подключиться к документу, не загрязняя документ.

С Angular работа html - это не просто документ, это должен быть уровень представления приложения, который для меня - гораздо большая работа. И чтобы заполнить эту работу Angular (и аналогичные структуры), мы можем сделать двустороннюю привязку с нашими данными и поведением декларативным способом, в то время как, как указывает смертный человек, сохраняя наши данные и поведение, хорошо разделенные и разделенные, а также проверяемым.

Фактически, теперь, когда я думаю об этом, на самом деле немного глупо поддерживать позицию, что ваш html должен быть чистым документом, но в то же время содержать кнопки и другие элементы управления, указывая, что это больше, чем документ, Может быть, это только я, но я нахожу это парадоксальным. Мне совершенно понятно, что мы объявляем, какое действие должно запускаться при управлении элементом управления.

Ответ 3

Недавно я изучал Angular и имел те же самые мысли, разве это не нарушает разделение проблем? Примеры, которые они приводят на своем сайте: "Не нарушайте разделение проблем!" Будучи вовлеченным в MVVM и MVC за последние 10 лет, я думаю, что Angular - это шаг назад к дням Cold Fusion. Не то, чтобы Cold Fusion и Angular не были сильными, они просто способствуют плохому дизайну.

Все исследования SDLC показывают, что 50-60% общей стоимости программного обеспечения находится в обслуживании, а не в разработке! Но большинство разработчиков думают (из-за сроков), они просто должны получить его там, и, к их чести, они делают! Тем не менее, проекты заканчиваются, разработчики оставляют, а остальным остается задаться вопросом, как поддержать эту базу кода.

Мы знаем о OOP и OOD уже много лет, а недавно видели попытки включить Javascript в эту проблему с расширениями, такими как JQuery. Хотя до тех пор, пока Javascript не станет языком OOD, он и все его расширения не будут действительно доступны. Комментарий выше "gloabal variables are bad" - хороший комментарий, но на сильно типизированных языках он НИКОГДА не беспокоится. Единственный раз, когда эти типы проблем возникают, когда фреймворк поддерживает его из коробки! Сильно типизированные языки могут иметь глобальные вары, если это необходимо, но область охвата является королем на этих языках, и это одна из первых вещей, которые преподаются.

Мой опыт на протяжении многих лет заключается в том, что программисты первые 1) Быстро, чтобы выполнить работу, прежде чем они узнают шаблоны, которые составляют хорошую технику. 2) В каждом крупном учреждении есть тонны кода, требующие серьезного повторного факторинга. 3) Проблемы с расширяемым не видны до тех пор, пока много лет спустя 4) Усилия по реинжинированию огромны! Все это хорошая новость для обеспечения безопасности работы, но в то же время, почему бы просто не сделать это правильно с самого начала?

JQuery, Javascript и даже Angular имеют свое место, но они также являются фреймворками, которые поощряют плохой дизайн для тех, кто не знает. Я нашел самый важный шаблон во всем программировании - это "шаблон наблюдателя", который мы видим в возможности создания обработчиков событий и создания событий. Затем развязка становится очень высокой в списке. Если у вас есть код, который большой по событиям и возможностям обработки событий, вы направляетесь в правильном направлении. Если вы повторно используете код и строго придерживаетесь того, чтобы не повторять то, что вы делаете хорошо. Наконец, если вы занимаетесь повторным факторингом со страстью и действительно понимаете мощь методов программирования на основе интерфейса, которые вы делаете хорошо. О да, еще одна вещь, если вы знаете, что такое инъекция зависимостей, вы являетесь генералом 5 звезд в армии программистов. Март, хорошие солдаты!

Ответ 4

Я использовал Knockout.js(который очень похож на angular в отношении концепций привязки данных) в течение последних двух лет в большом проекте. Основное преимущество, которое я вижу в наличии только некоторых имен функций в разметке, вместо реализации всей функции, заключается в том, что реализация может быть легко изменена без изменения разметки. Особенно, если разметка не полностью контролируется вами, как это было в нашем случае.

Дизайнер изменил разметку в соответствии с визуальными требованиями, в то время как мы просто сказали ему не вмешиваться в атрибуты привязки данных. Конечно, иногда он менял разметку настолько сильно, что нам нужно было изменять атрибуты привязки данных, но это в основном означало перемещение их из одного тега в другой, реализация не изменилась.