Jaki jest pożytek z Jade lub Handlebars podczas pisania aplikacji AngularJs

120

Jestem nowy (ish) w całej aplikacji pełnego stosu javascript i zupełnie nowy w Angular, więc miałem nadzieję, że ktoś umieści tutaj opis bezpośrednio dla mnie.

Dlaczego miałbym używać struktury szablonów, takiej jak Jade lub Handlebars, podczas pisania aplikacji po stronie klienta przy użyciu AngularJS.

Powinienem powiedzieć, że nigdy też nie korzystałem z żadnego z tych frameworków do tworzenia szablonów. Więc nie znam całkowicie zalet. Ale kiedy patrzę na przykład na kierownicę, robi wiele takich samych rzeczy, jak robiłbym w Angular, takich jak zapętlanie itp.

O ile wiem, najbardziej sensowne byłoby utworzenie szablonów w Angular przy użyciu odpowiedniego kodu HTML, a następnie wykonanie wszystkich szablonów po stronie klienta i połączenie tego z pierwszym podejściem API, na przykład przy użyciu węzła i mongo.

Powodem tego zamieszania jest to, że wiele przykładów, które znajduję na GitHub, wykorzystuje Jade i wydaje mi się to sprzeczne z intuicją.

Proszę, oświeć mnie i wyprostuj. Bardzo chciałbym nauczyć się sprawdzonych metod od ludzi, którzy wiedzą znacznie więcej niż ja.

Dzięki

node.js mongodb angularjs handlebars.js pug Jay Pete
źródło

Odpowiedzi:

61

Ci, którzy bezsprzecznie faworyzują Jade w środowisku Angular, nie rozumieją, że logika widoku należy do klienta, a logika biznesowa na serwerze, tak jak skomentował OP.

Nie rób tego, chyba że masz ku temu dobry powód. W inżynierii system z mniejszą liczbą ruchomych części jest bardziej niezawodny, a system, w którym przestrzegane są granice interfejsu (klient / serwer), jest łatwiejszy w utrzymaniu w perspektywie długoterminowej, więc jeśli to możliwe, wybierz najprostszą architekturę i czysty podział pracy. Jeśli masz nadrzędne powody, rób, co musisz, ale unikaj pustki .

Niedawno przejrzałem kod, w którym proste szablony Angular wykonałyby znacznie lepszą robotę niż mieszanie w Jade, tylko dzięki zachowaniu prostoty.

Oprócz rozszerzenia szablonu, Jade nie wnosi nic wartościowego do tabeli, której Angular jeszcze nie dostarcza. Bądźmy szczerzy: stosując rozsądną zasadę „faworyzuj kompozycję nad dziedziczeniem” (tj. Częściowe), nigdy nie powinieneś potrzebować rozszerzalności szablonów. Jade nie jest „łatwiejsze do przeanalizowania” niż HTML. Są jednak trywialnie różne, podczas gdy Jade dodaje kolejny poziom pośrednictwa - najlepiej go unikać.

Jest jeden ważny, wyspecjalizowany przypadek tworzenia szablonów po stronie serwera: optymalizacja, pamiętając, że przedwczesna optymalizacja jest ogólnie złą rzeczą. Tam, gdzie naprawdę ważna jest wydajność i masz wolne miejsce na serwerze, aby sobie z tym poradzić, pomocne może być tworzenie szablonów po stronie serwera. Dotyczy to produktów takich jak Twitter i Basecamp, w przypadku których koszt wykonywania dużej ilości pracy po stronie serwera jest równoważony korzyściami ze zmniejszenia liczby żądań do serwera.

Jeśli chodzi o kierownice, nie ma potrzeby zastępowania (niesamowitego) szablonów AngularJS po stronie klienta.

Inżynier
źródło
4
Cześć Nick, to jest odpowiedź, do której również dotarłem. Nie powiedziałem tego tak otwarcie, ale zgadzam się!
Jay Pete
60
@Nick, nie widziałem zbyt wielu ludzi, którzy lubią pisać / czytać XML / HTML. Prawdopodobnie jesteś najrzadszym człowiekiem, jakiego kiedykolwiek widziałem, który faktycznie opowiada się za czymś znacznie suchszym i czystszym, takim jak Jade. Istnieje mnóstwo bibliotek, których celem jest oszczędzanie ludziom pisania / czytania XML / HTML.
Alex K
12
Nie wprowadzam złożoności tam, gdzie nie jest to potrzebne. Spędzić dzień czytanie kodu C lub, co gorsza, C ++ Szablony, a będziesz szybko sobie sprawę, że psychicznie parsowania HTML jest bardzo banalna sprawa rzeczywiście .
Inżynier
35
„śmieszne dla każdego profesjonalisty, aby to twierdzić.”, „mentalne analizowanie kodu HTML jest rzeczywiście bardzo trywialną sprawą”. Uważam te komentarze za bardzo poniżające. Czy wolałbyś napisać asembler, ponieważ jest tak łatwy do przeanalizowania? Jade jest zasadniczo tym, czym YAML jest dla XML, gdy używasz z nim Angulara.
Philipp Gayret,
7
Zgadzam się z @NickWiggill. Mentalne parsowanie szablonu JADE w porównaniu z surowym kodem HTML wymaga dla mnie takiego samego czasu procesora „wetware”. Nie posunę się do stwierdzenia, że ​​jesteś nieprofesjonalny, jeśli się nie zgadzasz, ale dla mnie to to samo. @ Philipp, twoja analogia parsowania C / C ++ do asemblera równego parsowaniu JADE do HTML jest kiepska, jest niewielu ludzi, którzy mogliby nawet zacząć analizować assembler w czasie prawie rzeczywistym, podczas gdy wydaje mi się, że większość stron internetowych programiści mogli analizować HTML równie łatwo lub prawie tak łatwo, jak JADE.
nomis
63

Używam Jade do generowania szablonów używanych przez AngularJS, ponieważ nienawidzę pisać zwykłego HTML. Wygląda to mniej więcej tak:

.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'
    )

… Co moim zdaniem jest dużo czystsze niż zwykły HTML.

thatmarvin
źródło
12
OK, więc używasz go tylko dlatego, że nie lubisz pisać zwykłego HTML? Czy to główna korzyść dla Jade, czy są inne wygrane? Czy Jade kiedykolwiek zepsuło HTML w jakikolwiek sposób, więc musisz go poprawić, aby uzyskać określony wynik? Widzę niebezpieczeństwo dodania kolejnej warstwy pośredniej bez faktycznej potrzeby. Ale z drugiej strony, dlatego pytam. Chcę zrozumieć wartość tutaj.
Jay Pete,
1
Właściwie zacząłem od Jade, zanim poszedłem z Angularem, więc był to nawyk, który raczej utknął niż świadomy wybór, ale jak dotąd dobrze się sprawdził. Jedynym problemem, jaki mam z Jade, jest sposób, w jaki obsługuje on białe spacje (używam pretty = false), więc skończyło się na końcowych białych znakach w plikach źródłowych, gdy potrzebuję dodać spację między tagami. Uważam, że funkcje takie jak include i mixins są bardzo przydatne.
thatmarvin
Czy ng-inludeprawdopodobnie używany razem z ng-src, różni się znacznie od miksów Jades i zawiera?
Jay Pete,
2
Warstwa abstrakcji @JayPete Jade nad HTML jest bardzo cienka. To jedno z najbardziej intuicyjnych tłumaczeń między składniami, jakich kiedykolwiek używałem. Bardzo niewiele magii dzieje się w Jade, z wyjątkiem sytuacji, gdy zaczynasz wgłębiać się w zmienne i logikę warunkową (tak jak w przypadku każdego silnika szablonów). To naprawdę nie jest takie różne.
Chev
6
Proste jest subiektywne.
Chev
46

Naprawdę nie rozumiem, dlaczego ludziom zależy na różnicy między tym:

<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>

i to:

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")

Tyle że uważam, że jeden jest bardziej czytelny dla człowieka. Nieznacznie . Nie rozumiem, dlaczego ludzie tak żarliwie podchodzą do tego tematu. To wszystko dla rowerów. Różnica jest znikoma i każdy kompetentny programista mógłby łatwo przetłumaczyć jedno na drugie po pięciu sekundach w Google. Używaj tego, co chcesz i pozwól innym kłócić się o nic. Wybieraj swoje bitwy i angażuj się w debaty o rzeczach, które naprawdę mają znaczenie, takich jak reaktory atomowe;)

Chev
źródło
2
Zgadzam się, chociaż jeśli dodasz tylko 1 Jade ifdo równania, wszystko nagle się zmienia. Zobacz powyżej o „użytkownikach premium”.
TWiStErRob
15
Nie zgadzam się, 9-liniowa strona HTML jest całkowicie nierealna. pobranie źródła strony, którą przeglądam, konwertuje teraz 2320 wierszy na 1580 (przy użyciu html2jade ). To ponad 700 linijek czasu straconych dla każdego, kto napisał wszystkie szablony stackoverflow
Philipp Gayret,
2
@TWiStErRob Jeśli przechodzisz od Jade do HTML, wszystko, co musisz zrobić, to wyrenderować szablon, lol. Jeśli masz ifs w swoim jadeitowym znaczniku, to i tak potrzebujesz już jakiegoś silnika szablonów i musiałbyś przekonwertować go na dowolną ifskładnię używaną przez ten silnik. Naprawdę nie rozumiem twojej krytyki.
Chev
Jeśli cała ta debata dotyczy tego, gdzie należy logika warunkowa (serwer lub klient), to myślę, że jest to jeszcze głupsza debata niż pierwotnie. Istnieją przypadki dla obu i możesz użyć tego, który z nich działa, lub jeśli oboje będą to robić, w zależności od tego, co preferuje osoba. Spędziłem więcej czasu na kłótniach takich jak te, niż kiedykolwiek przeklinając wcześniejszą decyzję, aby umieścić jakąś logikę w widoku po stronie serwera lub odwrotnie. Jeśli wszyscy chcemy dyskutować o wydajności, powinniśmy zamiast tego omówić zalety całej tej rozmowy.
Chev
3
@Philipp, czy nie można bezpiecznie założyć, że większość usuniętych wierszy to tylko zamykające tagi? Ponieważ większość redaktorów automatycznie dodaje znaczniki zamykające, kiedy piszesz znacznik otwierający, wątpię, aby faktycznie zapisał 700 linii.
Średnik
14
  1. Nie musisz używać Handlebars z AngularJS, ponieważ ma on własny silnik szablonów.
  2. Powód, dla którego używają Jade, ponieważ jest to tylko renderer serwera, który zostanie skompilowany do html i obsługiwany przez angularJS później w interfejsie.

Tak więc TL; DR na serwerze możesz użyć dowolnego języka [jade, haml, ...] do wygenerowania tylko struktury html dla swojej aplikacji, nie ma to nic wspólnego z angularJS, ponieważ będzie renderować i działać z HTML na środowisko uruchomieniowe na frontend.

Nie musisz używać Jade na serwerze i sugeruję nie używać, ponieważ wprowadzi to w błąd nowych programistów. W projektach, które widzisz, używają Jade tylko dlatego, że jest czystszy i są do tego przyzwyczajeni, a jeśli używa z angularJS, jedynym zadaniem jest wygenerowanie czystego HTML bez żadnej logiki.

Dzung Nguyen
źródło
2
Czy nie byłoby czystsze, gdybyśmy nie korzystali z html generowanego przez serwer i całkowicie oddzielili logikę od widoku? A może jest coś, czego mi brakuje? Dlaczego Jade to dobry pomysł podczas pisania aplikacji AngularJS?
Jay Pete,
Nie mówię, że używanie angularJS jest dobrym pomysłem. Jade nie ma nic wspólnego z angularJS. Aby to wyjaśnić, zaktualizuję swoją odpowiedź.
Dzung Nguyen
Rozumiem, że Jade nie ma nic wspólnego z Angularem. Po prostu próbuję dowiedzieć się, jaka jest wartość Jade, nad pisaniem rzeczywistego HTML w częściach podrzędnych AngularJS. Widzę wiele osób, które go używają i chcę zrozumieć, dlaczego :-)
Jay Pete,
2
Ponownie, Jade nie ma nic wspólnego z AngularJS. AngularJS zbiera części HTML i jest obsługiwany ze strony HTML. Możesz użyć czegokolwiek, aby utworzyć strony HTML po stronie serwera, w tym Jade lub Haml. Jade / Haml nie są tak naprawdę frameworkami szablonowymi. Są bardziej preprocesorami. Prawidłowe pytanie brzmiałoby „Kierownica, wąsy lub inne języki szablonów JavaScript”
Eddie Monge Jr
@JayPete Korzyści z używania Jade podczas tworzenia angularJS, być może ze względu na składnię Jade, są czystsze. Ale mimo to, z powodu mojego doświadczenia, to niewiele pomaga. Więc po prostu zrób to z html :)
Dzung Nguyen
8

Przyjęta odpowiedź jest nieco jednostronna i pomija fakt, że każda konfiguracja prekompilatora dla HTML świetnie nadaje się do KAŻDEGO rodzaju projektu HTML: kompozycji i wynikającej z tego elastyczności znaczników.

Pracujesz sam nad aplikacją kątową? Spróbuj Jade.

Jade poprawia zdolność do modularyzacji HTML, zmniejsza ilość czasu spędzanego na debugowaniu HTML, a także zachęca do tworzenia spisów znaczników.

Podczas projektowania części HTML może być bardzo dużo iteracji. Jeśli dane wyjściowe HTML są oparte na zestawie plików jade, zespół może łatwo działać elastycznie w przypadku zmieniających się wymagań. Ponadto zmiana znaczników poprzez ponowne komponowanie dołączeń jade jest znacznie bardziej niezawodna niż ponowne pisanie czystego HTML.

Biorąc to pod uwagę, zdaję sobie sprawę z ogólnej niechęci do mieszania kątów z jadeitem na etapie produkcji lub rozwoju. Wprowadzenie kolejnego wymaganego zestawu wiedzy o składni jest złym pomysłem dla większości zespołów, a użycie jade może ukryć nieefektywne zarządzanie projektami poprzez oderwanie niektórych prac, które byłyby zabronione przez zasady DRY (np. Lenistwo w przygotowywaniu znaczników)

Mirko
źródło
2
Nie mam pojęcia, dlaczego to miało -1, ale sprzeciwiłem się temu.
Mark K Cowan
Został odrzucony, ponieważ nie jest do końca prawdziwy. Jade nie robi nic, aby modularyzować HTML. Możesz dosłownie powiedzieć to samo o zwykłym HTML, jeśli jest używany we właściwy sposób z prekompilatorem.
Justin
1
Masz rację, to samo można powiedzieć o wszystkich prekompilatorach. W przypadku Jade Mixins jade-lang.com/reference/mixins może poprawić modularyzację (zwłaszcza w porównaniu z waniliowym HTML). Jeśli jesteś zainteresowany modularyzacją HTML, możesz polubić również polimer-project.org .
Mirko
7

Przeczytałem wszystkie powyższe odpowiedzi i byłem trochę zaskoczony, że nikt nie wspomniał o jednym aspekcie, co sprawia, że ​​używanie jade zamiast generowania szablonów AngularJS jest bardzo przydatną rzeczą.

Jak już powiedziano, w produkcji realistyczne scenariusze różnią się między pisaniem surowego html a jade, ale ważniejszą rzeczą, o której nigdy nie powinniśmy zapominać, jest to, że czasami potrzebujemy dynamicznie zmienianych i ponownie zainicjowanych szablonów angularjs.

Mówiąc prościej, czasami musimy zmienić HTML za pomocą innerHTML, a następnie zmusić AngularJS do ponownej kompilacji zawartości. I to jest dokładnie ten rodzaj zadania, kiedy generowanie takich widoków przez jade może przynieść korzyści.

Ponadto AngularJS dobrze współpracuje z modelami, których struktura jest z definicji dobrze znana. Właściwie zdarza się, że tak naprawdę nie znamy dokładnej struktury (wyobraź sobie, powiedzmy, renderer JSON). AngularJS będzie tutaj dość niezdarny (nawet gdyby budował aplikację kątową), a jade zrobi to.

shabunc
źródło
2

Możesz dołączyć szablony kątowe za pośrednictwem Jade.

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

W przypadku szablonów buforowania postrzegam to jako znacznie mniej delikatne niż włączenie szablonów uciekających w plikach javascript.

Zobacz: https://docs.angularjs.org/api/ng/service/$templateCache

Austin Pray
źródło
2

Jade jest zdecydowanie bliżej html niż powiedzmy Haml. Tak więc zmiana kontekstu jest właściwie bardzo minimalna. Jednak nie jest całkowicie nieobecny. Dla dewelopera może to w ogóle nie mieć znaczenia. Ale kiedy projektant przychodzi i pyta, jak sprawić, by zagnieżdżony tag działał poprawnie, rozwiązujesz niepotrzebny problem, który stworzyłeś w pierwszej kolejności.

HTML można nadal pisać bardzo czytelnie, a częściowe mogą być używane, aby uczynić go bardziej zrozumiałym. 500 wierszy czegokolwiek jest trudnych do odczytania - czy to Jade, czy HTML.

Oto szablon Jade

.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

I odpowiednik 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>

Kiedy jest napisany czytelnie, nie uważam, aby HTML był szczególnie niekorzystny, aby uzasadniać zmianę. Rzeczywiście, kątowe wsporniki są obrzydliwe. Ale wolałbym je mieć, niż zajmować się wątpliwościami projektanta, czy wprowadzony przeze mnie kierunek łamania html. (Może nie. Ale udowodnienie, że nie jest to wartościowy wysiłek)

suryasankar
źródło
0

Po pierwsze, zawsze potrzebujesz jakiegoś szablonu po stronie serwera.

Tworzenie szablonów po stronie klienta ma ogromne wady w czasie ładowania, więc często jest łagodzone przez renderowanie niektórych statycznych elementów na serwerze. W ten sposób, gdy użytkownik częściowo załaduje stronę, będzie już widział niektóre elementy na stronie.

I cóż, szablony są przydatne w tym przypadku, chociaż ludzie czasami używają zamiast tego statycznego generatora HTML, takiego jak Jekyll.

Jest jeszcze jeden powód używania Jade, o którym wcześniej nie wspomniano.

Biała przestrzeń.

Jeśli piszesz obsługiwany przez człowieka kod HTML z wcięciami i znakami końca wiersza, każdy pojedynczy podział wiersza spowoduje powstanie węzła tekstowego spacji. W niektórych przypadkach może dość mocno przykręcić formatowanie elementów wbudowanych i sprawić, że kod javascript będzie bardziej dziwny.

Możesz przeczytać więcej szczegółów tutaj: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Jeśli piszesz kod Jade, jest on kompilowany do jednowierszowego kodu HTML, który nie ma tego problemu.

Alex
źródło
> [FasteRender] ( meteorhacks.com/fast-render ) to rozwiązanie, które nie obejmuje renderowania po stronie serwera. Wysyła dane wymagane do renderowania Twojej pierwszej strony z początkowym kodem HTML załadowanym z Meteor, więc strona jest renderowana zaraz po załadowaniu JavaScript do klienta. Daje identyczny wynik jak Renderowanie po stronie serwera (SSR), ale nadal przesyła dane przez sieć bez łamania jednej z podstawowych zasad Meteor.
Max Hodges,
0

Pracując w zespole, front-end prawdopodobnie preferuje projektowanie swoich stron jako statyczny html. Tłumaczenie tego statycznego html na dynamiczne szablony jest źródłem błędów, a dodanie jade dodaje taki krok do tłumaczenia.

Jak wielu innych, wolę prostotę!

Arjan
źródło