Какое использование Jade или Handlebars при написании приложений AngularJs

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

Зачем мне нужно использовать структуру шаблонов, такую ​​как Jade или Handlebars, при написании приложений на стороне клиента с помощью AngularJS.

Я должен сказать, что я никогда не использовал ни одну из этих шаблонных схем. Поэтому я полностью не знаком с преимуществами. Но когда я смотрю на Handlebars, например, он выполняет многие те же действия, что и в Angular, например, цикл и т.д.

Насколько я могу судить, было бы разумно создать шаблоны в Angular, используя надлежащий HTML, а затем сделать все шаблонирование клиентской стороны и объединить это с первым подходом API, используя node и mongo, например.

Причина этой путаницы в том, что многие примеры, которые я нахожу в GitHub, используют Jade, и для меня это кажется интуитивно понятным.

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

Спасибо

Ответ 1

Те, кто, несомненно, одобряют Jade в среде Angular, не понимают, что логика представления принадлежит клиенту и бизнес-логике на сервере, так же, как прокомментировал OP.

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

Недавно я просмотрел некоторый код, где прямая Angular templating сделала бы намного лучшую работу, чем смешивание в Jade, просто поддерживая простоту.

Помимо расширения шаблона, Jade не приносит ничего полезного в таблицу, которую Angular не предлагает. Позвольте быть честным: используя звуковой принцип "композиции предпочтения над наследованием" (т.е. Частичные), вам никогда не понадобится расширяемость шаблонов. Джейд вряд ли "легче разобрать", чем HTML. Они тривиально отличаются друг от друга, в то время как Джейд добавляет еще один уровень косвенности - лучше всего избегать.

Существует один действительный специализированный случай для шаблонов на стороне сервера: оптимизация, помня о том, что преждевременная оптимизация обычно является плохим. В тех случаях, когда производительность действительно проблема, и у вас есть емкость сервера, чтобы сэкономить на этом, серверная процедура может помочь. Это относится к таким продуктам, как Twitter и Basecamp, где затраты на работу на стороне сервера компенсируются увеличением количества запросов на сервер.

Что касается Handlebars, нет необходимости заменять шаблоны на стороне клиента AngularJS (удивительные).

Ответ 2

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

.control-group(
  ng-form
  name='emailGroup'
  ng-class='{"ng-error": emailGroup.$invalid}'
)
  label.control-label Email
  .controls
    input(
      type='email'
      ng-model='user.email'
      required
      placeholder='[email protected]'
      focus-on='focusEmail'
    )

..., который, по моему мнению, намного чище, чем простой HTML.

Ответ 3

Я честно не понимаю, почему люди заботятся о различии между этим:

<html ng-app>
 <!-- Body tag augmented with ngController directive  -->
 <body ng-controller="MyController">
   <input ng-model="foo" value="bar">
   <!-- Button tag with ng-click directive, and string expression 'buttonText' wrapped in "{{ }}" markup -->
   <button ng-click="changeFoo()">{{buttonText}}</button>
   <script src="angular.js">
 </body>
</html>

и это:

html(ng-app="ng-app")
  // Body tag augmented with ngController directive  
  body(ng-controller="MyController")
    input(ng-model="foo", value="bar")
    // Button tag with ng-click directive, and string expression 'buttonText' wrapped in "{{ }}" markup
    button(ng-click="changeFoo()") {{buttonText}}
    script(src="angular.js")

За исключением того, что я нахожу немного более понятным для человека. Слегка. Я не понимаю, почему люди так горячо относятся к этой теме. Все это bikeshedding. Разница незначительна, и любой компетентный программист может легко перевести один в другой через пять секунд в Google. Используйте то, что вы хотите, и пусть все остальные ссорятся ни с чем. Выбирайте свои битвы и занимайтесь дебатами о вещах, которые действительно имеют значение, например, атомные реакторы;)

Ответ 4

  • Вам не нужно использовать Handlebars с AngularJS, поскольку у него есть собственный механизм шаблонов.
  • Причина, по которой они используют Jade, потому что это просто средство отображения сервера, которое будет скомпилировано в html и будет обслуживаться angularJS позже на интерфейсе.

Итак, TL; DR, на сервере, вы можете использовать любой язык [jade, haml,...] для создания только html-структуры для вашего приложения, он не имеет ничего общего с angularJS, поскольку он будет отображать и работать с HTML во время выполнения на интерфейсе.

Вам не нужно использовать Jade на сервере, и я предлагаю не использовать его, поскольку он запутает новых разработчиков. В проектах, которые вы видите, они используют Jade только потому, что они более чистые, и они используются для него, и если он использует с angularJS, то только задание состоит в том, чтобы генерировать простой html без какой-либо логики.

Ответ 5

Принятый ответ несколько односторонний и пренебрегает тем фактом, что любая настройка предварительного компилятора для HTML имеет большое значение для ЛЮБОГО проекта HTML-проекта: состав и гибкость разметки.

Работа только в приложении angular? Попросите Джейд попробовать.

Jade улучшает вашу способность модулизовать HTML, уменьшает количество времени, потраченного на отладку HTML, а также поощряет сборку разметки.

Во время разработки может быть ужасное количество итераций на частях HTML. Если вывод HTML основан на наборе нефритовых файлов, команде легко действовать гибко при изменении требований. Кроме того, изменение разметки посредством перекомпоновки нефрита включает в себя значительно более надежную, чем переписывание чистого HTML.

Говоря, я признаю общее неприятие смешения angular с нефритом на стадии производства или разработки. Внедрение другого обязательного набора знаний по синтаксису является плохой идеей для большинства команд, и использование нефрита может скрыть неэффективное управление проектами, абстрагировав некоторые работы, которые будут запрещены DRY-принципами (например, ленивы при подготовке разметки).

Ответ 6

Я прочитал все ответы выше и был немного удивлен, никто не упомянул об одном аспекте, который делает использование jade над созданием шаблонов AngularJS очень полезной.

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

Проще говоря, иногда нам нужно изменить html через innerHTML, а затем заставить AngularJS перекомпилировать содержимое. И это именно тот тип задачи, когда создание таких представлений через нефрит может принести пользу.

Кроме того, AngularJS хорошо работает с моделями, структура которых по определению хорошо известна. На самом деле, случается так, что мы на самом деле не знаем точной структуры (предположим, скажем, JSON renderer). AngularJS будет довольно неуклюжим здесь (даже если они строят приложение angular), в то время как нефрит выполнит эту работу.

Ответ 7

Вы можете включить angular шаблоны через Jade.

script(type="text/ng-template", id="admin")
  include partials/admin

Для кэширования шаблонов я воспринимаю это гораздо менее хрупкое, чем включение экранированных шаблонов в файлы javascript.

Смотрите: https://docs.angularjs.org/api/ng/service/$templateCache

Ответ 8

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

HTML все еще можно писать очень разборчиво, а частичные можно использовать, чтобы сделать его более понятным. 500 строк ничего трудно читать - будь то Jade или HTML.

Вот шаблон нефрита

.product-container

    .input-group.msB.col-md-5.no-padding
        .fnt-light-navyblue.mtB(for='name')
            strong Name the sticker
        input.full-input(type='text', placeholder='Awesome Batman Sticker')
    .clear

    .form-group.mmT
        label.form-label.fnt-light-navyblue
            strong Choose size
        .selector-group(ng-repeat="size in sizes", ng-class="{ 'msT': !$first}")
            - raw
            span.radio
                input.radio(name='choose_sticker_size',
                            ng-model="selectedSize",
                            type='radio',
                            value='{{size}}',
                            id="sticker-{{size}}")
                span.fake-radio
            label(for='sticker-{{size}}') {{size}} inch
            - endraw
    // end form-group
    .clear

И эквивалентный HTML

<div class="product-container">

    <div class="input-group msB col-md-5 no-padding">
        <div for="name" class="fnt-light-navyblue mtB">
            <strong>Name the product</strong>
        </div>
        <input type="text" placeholder="Awesome Batman Sticker" class="full-input" />
    </div>
    <div class="clear"></div>

    <div class="form-group mmT">
        <label class="form-label fnt-light-navyblue">
            <strong>Choose size</strong>
        </label>
        <div
            class="selector-group"
            ng-class="{ 'msT': !$first}"
            ng-repeat="size in sizes">
                {% raw %}
                <span class="radio">
                    <input
                        id="sticker-{{size}}"
                        class="radio"
                        name="choose_sticker_size"
                        ng-model="selectedSize"
                        type="radio"
                        value="{{ size }}" />
                    <span class="fake-radio"></span>
                </span>
                <label for="sticker-{{size}}">{{size}}</label>
                {% endraw %}
        </div>
    </div><!-- end form-group -->
    <div class="clear"></div>
</div>

Когда я читаю разборчиво, я не вижу, чтобы HTML был особенно ущемлен, чтобы гарантировать переход. Разумеется, скобки angular - это бельмо на глазу. Но я предпочел бы иметь их, чем иметь дело с дизайнером, сомнения в том, что введенная косвенность нарушает html. (Возможно, это не так, но доказать это не стоит)

Ответ 9

Прежде всего, вам всегда нужен какой-то серверный шаблон.

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

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


Существует еще одна причина использования Jade, о которой ранее не упоминалось.

Пробелы.

Если вы пишете человеко-поддерживаемый HTML с углублениями и перерывами, каждый отдельный штрих приведет к пробелу node. В некоторых случаях он может сильно форматировать форматирование встроенных элементов и сделать код javascript более странным.

Подробнее вы можете прочитать здесь: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Если вы пишете Jade-код, он скомпилирован в однострочный HTML-код, который не имеет этой проблемы.

Ответ 10

При работе в команде front-end, вероятно, предпочитает создавать свои страницы как статические html. Перевод этого статического html в динамические шаблоны является источником ошибок, и добавление jade добавляет такой шаг перевода.

Как и многие другие, я выступаю за простоту!