AngularJs uygulamaları yazarken Jade veya Handlebars'ın kullanımı nedir


120

Tüm javascript tam yığın uygulamalarında yeniyim ve Angular'da tamamen yeniyim, bu yüzden birinin kaydı benim için doğrudan buraya koymasını umuyordum.

AngularJS kullanarak istemci tarafı uygulamaları yazarken neden Jade veya Handlebars gibi bir şablonlama çerçevesi kullanmam gerekir?

Bu şablonlama çerçevelerinin hiçbirini de hiç kullanmadım demeliyim. Bu yüzden avantajları tam olarak bilmiyorum. Ancak örneğin Gidon'a baktığımda, Angular'da yaptığımla aynı şeyleri yapıyor, örneğin döngü vb.

Anlayabildiğim kadarıyla, şablonları uygun HTML kullanarak Angular'da oluşturmak ve ardından tüm şablon oluşturma istemci tarafında yapmak ve bunu örneğin düğüm ve mongo kullanarak bir API ilk yaklaşımıyla birleştirmek en mantıklı olacaktır.

Bu karışıklığın nedeni, GitHub'da bulduğum birçok örneğin Jade'den yararlanıyor olması ve bu benim için mantıksız görünüyor.

Lütfen beni aydınlatın ve beni düzeltin. Benden çok daha fazlasını bilen insanlardan bazı en iyi uygulamaları öğrenmeyi çok isterim.

Teşekkürler

Yanıtlar:


61

Bir Angular ortamında Jade'i sorgusuz sualsiz tercih edenler , tıpkı OP'nin yorumladığı gibi, görüş mantığının istemciye ve iş mantığının sunucuya ait olduğunu anlamıyorlar.

Bunu yapmak için çok iyi bir sebebin yoksa yapma. Mühendislikte, daha az hareketli parçaya sahip bir sistem daha güvenilir bir sistemdir ve arayüz sınırlarına (istemci / sunucu) saygı duyulan bir sistem uzun vadede daha sürdürülebilirdir, bu nedenle mümkünse en basit mimariye ve temiz iş bölümüne varsayılan olarak atlayın. Önem veren nedenleriniz varsa, yapmanız gerekeni yapın, ancak imparatoru uyarın .

Son zamanlarda, basit Angular şablonlamanın sadece basitliği koruyarak Jade'de karıştırmaktan çok daha iyi bir iş çıkardığı bazı kodları gözden geçirdim.

Şablon uzantısının yanı sıra Jade, Angular'ın henüz tedarik etmediği masaya değerli hiçbir şey getirmiyor. Dürüst olalım: "Kalıtım yerine kompozisyonu tercih et" (yani kısmi) sağlam prensibini kullanarak, şablon genişletilebilirliğine asla ihtiyacınız olmamalı . Jade, HTML'den "ayrıştırması daha kolay" değildir. Jade başka bir dolaylılık seviyesi eklerken - en iyisi kaçınılması gereken - bunlar önemsiz bir şekilde farklıdır.

Sunucu tarafı şablonlama için geçerli, özel bir durum vardır: Optimizasyon, erken optimizasyonun genellikle Kötü Bir Şey olduğunu hatırlamak. Performansın gerçekten söz konusu olduğu ve bunun üstesinden gelmek için yedek sunucu kapasitesine sahip olduğunuz durumlarda, sunucu tarafında şablon oluşturma yardımcı olabilir. Bu, çok sayıda sunucu tarafı iş yapmanın maliyetinin, sunucuya yapılan azalan isteklerin kazançları ile dengelendiği Twitter ve Basecamp gibi ürünler için geçerlidir.

Gidonlara gelince, AngularJS'nin (şaşırtıcı) istemci tarafı şablonunu değiştirmeye gerek yoktur.


4
Merhaba Nick, benim de ulaştığım cevap bu. Açıkça ifade etmedim, ama katılıyorum!
Jay Pete

60
@Nick, XML / HTML yazmayı / okumayı seven pek fazla insan görmedim. Jade gibi daha kuru ve temiz bir şey lehine bunu savunan, muhtemelen gördüğüm en nadir kişisiniz. Tüm amacı insanları XML / HTML yazmaktan / okumaktan kurtarmak olan tonlarca kütüphane var.
Alex K

12
İhtiyaç duyulmayan yerlerde karmaşıklık getirmiyorum. Günlerinizi C kodunu veya daha kötüsü C ++ şablonlarını okuyarak geçirin ve HTML'yi zihinsel olarak çözümlemenin gerçekten çok önemsiz bir konu olduğunu çabucak anlayacaksınız .
Engineer

35
"Herhangi bir profesyonelin bunu iddia etmesi gülünç.", "HTML'yi zihinsel olarak ayrıştırmak gerçekten çok önemsiz bir konu." Bu çok aşağılayıcı yorumlar buluyorum. Çözümlemesi çok kolay olduğu için assembly yazmayı mı tercih edersiniz? Jade, Angular'ı kullanırken temelde XML için YAML'nin ne olduğudur.
Philipp Gayret

7
@NickWiggill'e katılıyorum. Bir JADE şablonunu işlenmemiş HTML ile zihinsel olarak ayrıştırmak benim için eşit 'wetware' cpu süresi gerektiriyor. Aynı fikirde değilseniz, amatörce olduğunuzu söyleyecek kadar ileri gitmeyeceğim, ama benim için aynı şey. @ Philipp, C / C ++ 'yı birleştirmenin JADE'i HTML'ye ayrıştırmaya eşit olduğu benzetmeniz zayıftır, eğer varsa, derlemeyi neredeyse gerçek zamanlı olarak ayrıştırmaya başlayabilecek çok az insan var, oysa çoğu web geliştiriciler HTML'yi JADE kadar kolay veya neredeyse çok kolay ayrıştırabilirler.
nomis

63

Jade'i AngularJS tarafından tüketilen şablonlar oluşturmak için kullanıyorum çünkü düz HTML yazmaktan nefret ediyorum. Şuna benzer:

.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='you@example.com'
      focus-on='focusEmail'
    )

… Bence düz HTML'den çok daha temiz.


12
Tamam, yani sadece düz HTML yazmayı sevmediğin için mi kullanıyorsun? Jade'in ana faydası bu mu, başka kazançlar var mı? Jade HTML'yi herhangi bir şekilde karıştırdı mı, yani belirli bir çıktı elde etmek için onu ince ayarlamanız gerekiyor mu? Gerçek bir ihtiyaç olmadan başka bir yönlendirme katmanı eklemenin tehlikesini görüyorum . Ama yine de, bu yüzden soruyorum. Buradaki değeri anlamak istiyorum.
Jay Pete

1
Aslında Angular'a gitmeden önce Jade ile başladım, bu yüzden bilinçli bir seçimden çok sıkışan bir alışkanlıktı, ama şimdiye kadar iyi sonuç verdi. Jade ile yaşadığım tek sorun, beyaz boşlukları işleme biçimidir (güzel = yanlış kullanıyorum), bu nedenle, etiketler arasına bir boşluk eklemem gerektiğinde kaynak dosyalarda beyaz boşluklarla sonuçlandım. İnclude ve mixins gibi özellikleri çok kullanışlı buldum.
thatmarvin

Mu ng-inlude, muhtemelen birlikte kullanılan ng-srcJades Mixins gelen çok, farklılık ve ve içerir?
Jay Pete

2
HTML üzerinde soyutlama @JayPete Jade'in tabakasıdır soooo ince. Şimdiye kadar kullandığım sözdizimleri arasındaki en sezgisel çevirilerden biri. Jade'de değişkenler ve koşullu mantıkla (herhangi bir şablon motorunda yapacağınız gibi) incelemeye başladığınız yer dışında çok az sihir gerçekleşir. Gerçekten o kadar da farklı değil.
Chev

6
Basit özneldir.
Chev

46

Dürüst olmak gerekirse, insanların neden bunun arasındaki farkı önemsediğini anlamıyorum:

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

ve bu:

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

İnsan tarafından okunabilir bir tane daha bulmam dışında. Biraz . İnsanların bu konu hakkında neden bu kadar ateşli olduğunu anlamıyorum. Hepsi bisiklet düğün. Fark ihmal edilebilir düzeydedir ve herhangi bir yetkin programcı Google'da beş saniye sonra birini diğerine kolayca çevirebilir. İstediğinizi kullanın ve herkesin hiçbir şey için tartışmasına izin verin. Savaşlarınızı seçin ve atomik reaktörler gibi gerçekten önemli olan şeyler hakkında tartışmalara katılın;)


2
Katılıyorum, yine ifde denkleme 1 Jade eklerseniz , her şey aniden değişir. "Premium kullanıcılar" hakkında yukarıya bakın.
TWiStErRob

15
Katılmıyorum, 9 satırlık bir html sayfası tamamen gerçekçi değil. Şimdi görüntülediğim sayfanın kaynağını alarak 2320 satırı 1580'e çeviriyor ( html2jade kullanarak ). Bu , tüm
yığın akışı

2
@TWiStErRob Yeşimden HTML'ye geçiyorsanız tek yapmanız gereken şablonu oluşturmaktır, lol. Eğer varsa ifsizin yeşim işaretlemesindeki s o zaman zaten yine templating motorun çeşit için bir ihtiyaç varsa ve her ne dönüştürmek zorunda kalacak ifo motoru tarafından kullanılan sözdizimi. Eleştirinizi gerçekten anlamıyorum.
Chev

Eğer tüm bu tartışma koşullu mantığın (sunucu veya istemci) ait olduğu yer hakkındaysa, bence bu ilk başta yaptığımdan daha aptalca bir tartışma. Her ikisi için de durumlar vardır ve siz hangisi işe yararsa onu kullanırsınız ya da her ikisi de hangisini tercih ederse o zaman. Ben ettik daha bunlar gibi argümanları olan daha zaman geçirmesi hiç tersi bir sunucu tarafı görünümü veya mengeneye bazı mantık koymak için bir geçmiş kararını küfür geçirdi. Hepimiz verimlilik hakkında tartışmak istiyorsak, bunun yerine tüm bu konuşmanın faziletlerinden bahsetmeliyiz.
Chev

3
@Philipp, kaldırılan satırların çoğunun sadece kapanış etiketleri olduğunu varsaymak güvenli değil mi? Bir açılış etiketi yazdığınızda çoğu editör otomatik olarak kapanış etiketleri eklediğinden, aslında 700 satır yazmaktan tasarruf ettiğinden şüpheliyim.
Noktalı virgül

14
  1. Kendi şablon motoruna sahip olduğu için AngularJS ile Gidon kullanmanıza gerek yoktur.
  2. Jade'i kullanmalarının nedeni, html'ye derlenecek ve daha sonra ön uçta angularJS tarafından sunulacak bir sunucu oluşturucu.

Yani TL; DR, sunucuda, uygulamanız için sadece html yapısı oluşturmak için hangi dili [jade, haml, ...] kullanabilirsiniz, HTML'de render edeceği ve HTML ile çalışacağı için angularJS ile hiçbir ilgisi yoktur. ön uçta çalışma zamanı.

Jade'i sunucuda kullanmak zorunda değilsiniz ve yeni geliştiricilerin kafasını karıştıracağı için kullanmamanızı öneririm. Gördüğünüz projelerde Jade'i yalnızca daha temiz olduğu ve buna alıştıkları için kullandıklarını ve angularJS ile kullanılıyorsa, tek işi herhangi bir mantık olmadan düz html oluşturmaktır.


2
Sunucu tarafından oluşturulan html'yi kullanmamak ve mantık ile görünümü tamamen ayırmak daha temiz olmaz mıydı? Yoksa kaçırdığım bir şey mi var? AngularJS uygulaması yazarken Jade neden iyi bir fikirdir?
Jay Pete

AngularJS ile kullanmanın iyi bir fikir olduğunu söylemiyorum. Jade'in angularJS ile ilgisi yok. Bunu netleştirmek için cevabımı güncelleyeceğim.
Dzung Nguyen

Jade'in Angular'la ilgisi olmadığını anlıyorum. AngularJS bölümlerinde gerçek HTML'yi yazmak yerine Jade'in değerinin ne olduğunu anlamaya çalışıyorum. Birçok kişinin bunu kullandığını görüyorum ve nedenini anlamak istiyorum :-)
Jay Pete 13

2
Jade'in AngularJS ile ilgisi yok. AngularJS, HTML parçalarını içerir ve bir HTML sayfasından sunulur. Jade veya Haml dahil olmak üzere sunucu tarafında HTML sayfalarını yapmak için her şeyi kullanabilirsiniz. Jade / Haml, gerçekten çerçeveler oluşturmuyor. Daha çok ön işlemcidirler. Doğru soru "Gidon veya Bıyık veya diğer JavaScript şablon dilleri" olacaktır
Eddie Monge Jr

@JayPete AngularJS geliştirirken Jade kullanmanın yararı belki Jade sözdizimi nedeniyle daha temizdir. Ama yine de deneyimlerime göre pek yardımı olmadı. Öyleyse sadece html ile yapın :)
Dzung Nguyen

8

Kabul edilen cevap bir şekilde tek yönlüdür ve HTML için herhangi bir ön derleyici kurulumunun HERHANGİ bir tür HTML projesi için harika bir kullanımı olduğu gerçeğini ihmal eder: Kompozisyon ve sonuçta ortaya çıkan biçimlendirme esnekliği.

Açısal bir uygulamada yalnız mı çalışıyorsunuz? Jade'e bir şans ver.

Jade, HTML'yi modülerleştirme yeteneğinizi geliştirir, HTML'de hata ayıklamak için harcadığınız zamanı azaltır ve ayrıca biçimlendirme envanterleri oluşturmayı teşvik eder.

Tasarım süresi boyunca, HTML parçalarında çok fazla sayıda yineleme olabilir. HTML çıktısı bir dizi jade dosyasına dayanıyorsa, ekibin değişen gereksinimler konusunda esnek davranması kolaydır. Ayrıca, yeşim içeriklerini yeniden oluşturma yoluyla işaretlemeyi değiştirmek, saf HTML'yi yeniden yazmaktan önemli ölçüde daha sağlamdır.

Bununla birlikte, üretim veya geliştirme aşamasında köşeli yeşim ile karıştırmaya yönelik genel tiksintinin farkındayım. Bir dizi gerekli sözdizimi bilgisinin tanıtılması, çoğu ekip için kötü bir fikirdir ve yeşim taşı kullanımı, DRY ilkeleri tarafından yasaklanabilecek bazı işleri soyutlayarak (örneğin, işaretleme hazırlığında tembel olmak) verimsiz proje yönetimini gizleyebilir.


2
Neden -1 olduğu hakkında hiçbir fikrim yok, ama ben buna karşı çıktım.
Mark K Cowan

Tamamen doğru olmadığı için olumsuz oy verildi. Jade, HTML'yi modülerleştirmek için hiçbir şey yapmaz. Bir ön derleyici ile doğru şekilde kullanılırsa, düz HTML hakkında kelimenin tam anlamıyla aynı şeyleri söyleyebilirsiniz.
Justin

1
Haklısınız, aynı şey tüm ön derleyiciler için söylenebilir. Jade için, Mixins jade-lang.com/reference/mixins modülerleştirmeyi geliştirebilir (özellikle vanilya HTML ile karşılaştırıldığında). HTML'nin modülerleştirilmesiyle ilgileniyorsanız, polymer- project.org'u da beğenebilirsiniz .
Mirko

7

Yukarıdaki tüm cevapları okudum ve kimsenin AngularJS şablonları oluşturmak yerine yeşim kullanmayı çok yararlı bir şey haline getiren bir yönden bahsetmemiş olmasına biraz şaşırdım.

Daha önce söylendiği gibi, üretimde, ham html ve jade yazmak arasındaki gerçekçi senaryo farkı aslında dikkate değerdir, ancak asla unutmamamız gereken en önemli şey, bazen dinamik olarak değiştirilmiş ve yeniden başlatılmış açısaljs şablonlarına ihtiyacımız olmasıdır.

Basitçe söylemek gerekirse, bazen html'yi innerHTML yoluyla değiştirmemiz ve ardından AngularJS'yi içeriği yeniden derlemeye zorlamamız gerekir. Ve yeşim yoluyla bu tür görünümler oluştururken faydaları olabilir.

Ayrıca, AngularJS, yapı tanımı gereği iyi bilinen modellerle iyi çalışır. Aslında, yapıyı tam olarak bilmediğimiz oluyor (örneğin JSON oluşturucuyu hayal edin). AngularJS burada oldukça beceriksiz olacak (açısal bir uygulama oluşturuyor olsalar bile), yeşim ise işi yapacak.



2

Jade kesinlikle html'ye Haml'den çok daha yakın. Dolayısıyla bağlam anahtarı aslında çok azdır. Yine de tamamen yok değil. Bir geliştirici için hiç önemli olmayabilir. Ancak tasarımcınız gelip size iç içe etiketin düzgün çalışmasını nasıl sağlayacağınızı sorduğunda, ilk başta yarattığınız gereksiz bir sorunu çözüyorsunuz.

HTML hala çok okunaklı bir şekilde yazılabilir ve onu daha anlaşılır kılmak için parçalar kullanılabilir. İster Jade ister HTML olsun, herhangi bir şeyin 500 satırını okumak zordur.

İşte bir Jade şablonu

.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

Ve eşdeğer 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>

Okunaklı bir şekilde yazıldığında, bir geçişi garanti edecek şekilde HTML'nin özellikle dezavantajlı olduğunu görmüyorum. Yeterince kesin, köşeli parantezler göze batıyor. Ancak, tasarımcının benim sunduğum dolaylı yöntemin html'yi bozup bozmadığına dair şüpheleriyle uğraşmak yerine onlara sahip olmayı tercih ederim. (Olmayabilir. Ancak bunun değerli bir çaba olmadığını kanıtlamak)


0

Her şeyden önce, her zaman bir tür sunucu tarafı şablonlamaya ihtiyacınız vardır.

Tamamen istemci tarafı şablonlamanın yükleme süresinde büyük dezavantajları vardır, bu nedenle genellikle sunucuda bazı statik öğeler oluşturarak hafifletilir. Bu şekilde, kullanıcı bir sayfayı kısmen yüklediğinde, sayfada zaten bazı öğeler görecektir.

Ve bu durumda şablonlar kullanışlıdır, ancak insanlar bazen bunun yerine Jekyll gibi statik html oluşturucu kullanır.


Jade'i kullanmanın daha önce burada belirtilmeyen başka bir nedeni daha var.

Beyaz boşluk.

İnsan tarafından bakımı yapılabilen, girintili ve satır sonlu HTML yazıyorsanız, her satır sonu bir boşluk metin düğümüyle sonuçlanacaktır. Bazı durumlarda satır içi öğelerin biçimlendirmesini büyük ölçüde bozabilir ve javascript kodunu daha tuhaf hale getirebilir.

Daha fazla ayrıntıyı buradan okuyabilirsiniz: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Jade kodu yazıyorsanız, bu sorunu olmayan tek satırlık HTML olarak derlenir.


> [FasteRender] ( meteorhacks.com/fast-render ), sunucu tarafında oluşturmayı içermeyen bir çözümdür. Meteor'dan yüklenen ilk HTML ile ilk sayfanızı oluşturmak için gereken verileri gönderir, böylece sayfa, JavaScript istemciye yüklendikten hemen sonra oluşturulur. Sunucu Tarafı Oluşturma (SSR) ile aynı sonucu verir, ancak yine de Meteor'un temel ilkelerinden birini bozmadan kablo üzerinden veri göndermeye devam eder.
Max Hodges

0

Bir takımda çalışırken, ön uç muhtemelen sayfalarını statik html olarak tasarlamayı tercih ediyor. Statik html'yi dinamik şablonlara çevirmek bir hata kaynağıdır ve jade eklemek bu tür bir çeviri adımını ekler.

Diğerleri gibi ben de basitliği destekliyorum!

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.