Công dụng của Jade hoặc Handlebars khi viết ứng dụng AngularJs


120

Tôi là người mới (ish) đối với toàn bộ các ứng dụng javascript full stack và hoàn toàn mới đối với Angular, vì vậy tôi hy vọng ai đó có thể đặt hồ sơ ngay cho tôi ở đây.

Tại sao tôi cần sử dụng khuôn khổ tạo mẫu như Jade hoặc Handlebars khi viết ứng dụng phía máy khách bằng AngularJS.

Tôi nên nói rằng tôi cũng chưa bao giờ sử dụng bất kỳ khuôn khổ khuôn mẫu nào. Vì vậy, tôi hoàn toàn không quen thuộc với những lợi thế. Nhưng khi tôi nhìn vào Handlebars chẳng hạn, nó thực hiện nhiều điều tương tự như tôi sẽ làm trong Angular, chẳng hạn như lặp lại, v.v.

Theo như tôi có thể nói, sẽ có ý nghĩa nhất nếu tạo các mẫu trong Angular bằng cách sử dụng HTML thích hợp và sau đó thực hiện tất cả các phía máy khách tạo mẫu và kết hợp điều này với cách tiếp cận API đầu tiên sử dụng nút và mongo chẳng hạn.

Lý do cho sự nhầm lẫn này là rất nhiều ví dụ tôi tìm thấy trên GitHub sử dụng Jade, và nó có vẻ không trực quan đối với tôi.

Xin hãy soi sáng cho tôi, và giúp tôi thẳng thắn. Tôi rất thích học một số phương pháp hay nhất từ ​​những người biết nhiều hơn tôi.

Cảm ơn

Câu trả lời:


61

Những người không nghi ngờ gì về Jade trong môi trường Angular không hiểu rằng logic chế độ xem thuộc về máy khách và logic nghiệp vụ trên máy chủ, giống như OP đã nhận xét.

Đừng làm điều đó trừ khi bạn có lý do chính đáng để làm điều đó. Trong kỹ thuật, một hệ thống có ít bộ phận chuyển động hơn là một hệ thống đáng tin cậy hơn và một hệ thống mà các ranh giới giao diện (máy khách / máy chủ) được tôn trọng sẽ dễ bảo trì hơn trong thời gian dài, vì vậy hãy mặc định là kiến ​​trúc đơn giản nhất và phân công lao động rõ ràng nếu có thể. Nếu bạn có những lý do chính đáng, hãy làm những gì bạn phải làm, nhưng hãy lưu ý .

Gần đây, tôi đã xem xét một số mã trong đó tạo khuôn dạng Angular thẳng sẽ thực hiện công việc tốt hơn nhiều so với trộn trong Jade, chỉ thông qua việc duy trì sự đơn giản.

Ngoài phần mở rộng mẫu, Jade không mang lại gì đáng giá cho bảng mà Angular chưa cung cấp. Thành thật mà nói: Sử dụng nguyên tắc âm thanh của "thành phần ưu tiên hơn kế thừa" (tức là các phần tử), bạn sẽ không bao giờ cần khả năng mở rộng khuôn mẫu. Jade hầu như không "dễ phân tích cú pháp" hơn HTML. Chúng khác nhau một cách đáng kể , trong khi Jade bổ sung thêm một cấp độ chuyển hướng khác - tốt nhất là nên tránh.

Có một trường hợp hợp lệ, chuyên biệt cho việc tạo khuôn mẫu phía máy chủ: Tối ưu hóa, hãy nhớ rằng việc tối ưu hóa quá sớm nói chung là Điều tồi tệ. Khi hiệu suất thực sự có vấn đề bạn có dung lượng máy chủ dự phòng để xử lý việc này, tính năng tạo khuôn mẫu phía máy chủ có thể hỗ trợ. Điều này áp dụng cho các sản phẩm như Twitter và Basecamp, nơi chi phí thực hiện nhiều công việc phía máy chủ được bù đắp bằng lợi ích của các yêu cầu giảm đến máy chủ.

Đối với Handlebars, không cần phải thay thế khuôn mẫu phía máy khách (tuyệt vời) của AngularJS.


4
Xin chào Nick, đó cũng là câu trả lời mà tôi đã đạt được. Tôi không nói thẳng ra như vậy, nhưng tôi đồng ý!
Jay Pete

60
@Nick, tôi không thấy nhiều người thích viết / đọc XML / HTML. Bạn có thể là người hiếm nhất mà tôi từng thấy thực sự ủng hộ điều đó ủng hộ một thứ gì đó khô hơn và sạch hơn như Ngọc. Có rất nhiều thư viện mà mục đích của nó là giúp mọi người không phải viết / đọc XML / HTML.
Alex K

12
Tôi không giới thiệu sự phức tạp khi nó không cần thiết. Dành cả ngày để đọc mã C hoặc tệ hơn là các mẫu C ++, và bạn sẽ nhanh chóng nhận ra rằng việc phân tích cú pháp HTML thực sự là một vấn đề rất tầm thường .
Kỹ sư

35
"thật nực cười cho bất kỳ chuyên gia nào tuyên bố điều này.", "về mặt tinh thần phân tích cú pháp HTML thực sự là một vấn đề rất tầm thường.". Tôi thấy những bình luận rất hèn hạ. Bạn có muốn viết assembly vì nó rất dễ phân tích cú pháp không? Về cơ bản, Jade là YAML dành cho XML khi bạn đang sử dụng Angular với nó.
Philipp Gayret

7
Tôi đồng ý với @NickWiggill. Về mặt tinh thần, phân tích cú pháp mẫu JADE so với HTML thô đòi hỏi thời gian cpu 'phần mềm ướt' bằng nhau đối với tôi. Tôi sẽ không đi quá xa khi nói rằng bạn không chuyên nghiệp nếu bạn không đồng ý, nhưng với tôi đó là điều tương tự. @ Philipp, sự tương tự của bạn về việc phân tích cú pháp C / C ++ thành hợp ngữ ngang bằng với việc phân tích cú pháp JADE thành HTML là kém, có rất ít người, nếu có, thậm chí có thể bắt đầu phân tích cú pháp hợp ngữ gần thời gian thực, trong khi tôi cảm thấy, hầu hết các trang web các nhà phát triển có thể phân tích cú pháp HTML dễ dàng hoặc gần như dễ dàng như JADE.
nomis

63

Tôi sử dụng Jade để tạo các mẫu được AngularJS sử dụng vì tôi ghét viết HTML thuần túy. Nó trông giống như sau:

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

… Mà tôi nghĩ là sạch hơn rất nhiều so với HTML thuần túy.


12
OK, vậy bạn chỉ sử dụng nó vì bạn không thích viết HTML thuần túy? Đó có phải là lợi ích chính đối với Ngọc, có những chiến thắng khác? Jade có bao giờ làm xáo trộn HTML theo bất kỳ cách nào, vì vậy bạn phải chỉnh sửa nó để có được một đầu ra nhất định? Tôi thấy nguy cơ đã thêm một lớp chuyển hướng khác mà không có nhu cầu thực tế. Nhưng một lần nữa, đó là lý do tôi hỏi. Tôi muốn hiểu giá trị ở đây.
Jay Pete

1
Tôi thực sự đã bắt đầu với Jade trước khi bắt đầu với Angular, vì vậy đó là một thói quen mắc kẹt hơn là một lựa chọn có ý thức, nhưng nó đã hoạt động tốt cho đến nay. Vấn đề duy nhất tôi gặp phải với Jade là cách nó xử lý khoảng trắng (tôi sử dụng khá = false) vì vậy tôi đã kết thúc với khoảng trắng ở cuối trong các tệp nguồn bất cứ khi nào tôi cần thêm khoảng trắng giữa các thẻ. Tôi thấy các tính năng như bao gồm và mixin rất hữu ích.
thatmarvin

Liệu ng-inlude, có thể được sử dụng cùng với ng-src, có khác nhiều với các mixin và và bao gồm của Jades không?
Jay Pete

2
Lớp trừu tượng của @JayPete Jade trên HTML quá mỏng. Đó là một trong những bản dịch trực quan nhất giữa các cú pháp mà tôi từng sử dụng. Rất ít phép thuật xảy ra trong Jade ngoại trừ trường hợp bạn bắt đầu đào sâu với các biến và logic có điều kiện (như bạn làm với bất kỳ công cụ mẫu nào). Nó thực sự không phải là tất cả khác nhau.
Chev

6
Đơn giản là chủ quan.
Chev

46

Tôi thành thật không hiểu tại sao mọi người lại quan tâm đến sự khác biệt giữa điều này:

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

và điều này:

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

Ngoại trừ việc tôi thấy một cuốn sách dễ đọc hơn một chút. Một chút . Tôi không hiểu tại sao mọi người lại nhiệt tình về chủ đề này như vậy. Tất cả đều là xe đạp. Sự khác biệt là không đáng kể và bất kỳ lập trình viên có năng lực nào cũng có thể dễ dàng dịch cái này sang cái kia sau năm giây trên Google. Sử dụng những gì bạn muốn và để mọi người khác cãi nhau không có gì. Chọn trận chiến của bạn và tham gia tranh luận về những thứ thực sự quan trọng, như lò phản ứng nguyên tử;)


2
Tôi đồng ý, mặc dù nếu bạn chỉ thêm 1 viên ngọc ifvào phương trình, mọi thứ sẽ đột ngột thay đổi. Xem ở trên về "người dùng cao cấp".
TWiStErRob

15
Tôi không đồng ý, một trang html 9 dòng là hoàn toàn không thực tế. lấy nguồn của trang tôi đang xem hiện chuyển đổi 2320 dòng thành 1580 (Sử dụng html2jade ). Thats hơn 700 dòng thời gian lãng phí cho bất cứ ai đã viết tất cả các mẫu stackoverflow
Philipp Gayret

2
@TWiStErRob Nếu bạn đang chuyển từ ngọc sang HTML, tất cả những gì bạn cần làm là hiển thị mẫu, lol. Nếu bạn có ifs trong phần đánh dấu bằng ngọc bích của mình thì dù sao thì bạn cũng đã có nhu cầu về một loại công cụ tạo khuôn mẫu nào đó và bạn phải chuyển đổi nó thành bất kỳ ifcú pháp nào được công cụ đó sử dụng. Tôi không thực sự hiểu lời chỉ trích của bạn.
Chev

Nếu toàn bộ cuộc tranh luận này là về nơi logic có điều kiện thuộc về (máy chủ hoặc máy khách) thì tôi nghĩ đó là một cuộc tranh luận thậm chí còn buồn hơn tôi đã làm ban đầu. Có những trường hợp cho cả hai và bạn sử dụng cái nào phù hợp hoặc nếu cả hai đều thích hợp thì tùy cá nhân thích. Tôi đã dành nhiều thời gian để có những lập luận như thế này hơn là tôi đã từng nguyền rủa một quyết định trong quá khứ để đưa một số logic vào chế độ xem phía máy chủ hoặc ngược lại. Nếu tất cả chúng ta đều muốn tranh luận về hiệu quả thì thay vào đó chúng ta nên thảo luận về giá trị của toàn bộ cuộc trò chuyện này.
Chev

3
@Philipp, không an toàn khi cho rằng hầu hết các dòng bị xóa chỉ là thẻ đóng? Vì hầu hết các trình chỉnh sửa tự động thêm thẻ đóng khi bạn viết thẻ mở, tôi nghi ngờ rằng nó thực sự tiết kiệm được việc viết 700 dòng.
Dấu chấm phẩy

14
  1. Bạn không cần sử dụng Handlebars với AngularJS vì nó có công cụ mẫu riêng.
  2. Lý do họ sử dụng Jade, vì nó chỉ là một trình kết xuất máy chủ sẽ được biên dịch thành html và được phục vụ bởi angleJS sau này trên giao diện người dùng.

Vì vậy, TL; DR, trên máy chủ, bạn có thể sử dụng bất kỳ ngôn ngữ nào [jade, haml, ...] để chỉ tạo cấu trúc html cho ứng dụng của bạn, nó không liên quan gì đến angleJS vì nó sẽ hiển thị và hoạt động với HTML tại thời gian chạy trên giao diện người dùng.

Bạn không nhất thiết phải sử dụng Ngọc trên máy chủ và tôi khuyên bạn không nên sử dụng vì nó sẽ khiến các nhà phát triển mới bối rối. Trong các dự án mà bạn thấy, họ chỉ sử dụng Jade vì nó sạch hơn và họ đã quen với nó, và nếu nó sử dụng với angleJS, công việc duy nhất là tạo html đơn giản mà không có bất kỳ logic nào.


2
Sẽ không dễ dàng hơn nếu không sử dụng html do máy chủ tạo, và hoàn toàn tách biệt logic và chế độ xem? Hay có điều gì đó tôi đang thiếu? Tại sao Jade là một ý tưởng hay khi viết ứng dụng AngularJS?
Jay Pete

Tôi không nói là một ý tưởng hay để sử dụng với angleJS. Jade không liên quan gì đến AngJS. Để làm rõ điều này, tôi sẽ cập nhật câu trả lời của mình.
Dzung Nguyen

Tôi hiểu rằng Jade không liên quan gì đến Angular. Tôi chỉ đang cố gắng tìm ra giá trị của Jade, bằng cách viết ra HTML thực tế trong AngularJS partials. Tôi thấy rất nhiều người sử dụng nó, và muốn hiểu tại sao :-)
Jay Pete

2
Một lần nữa, Jade không liên quan gì đến AngularJS. AngularJS kết hợp các phần tử HTML và được cung cấp từ một trang HTML. Bạn có thể sử dụng bất kỳ thứ gì để tạo các trang HTML ở phía máy chủ, bao gồm cả Jade hoặc Haml. Jade / Haml không thực sự là khuôn khổ tạo khuôn mẫu. Chúng là những bộ tiền xử lý nhiều hơn. Câu hỏi chính xác sẽ là "Handlebars hoặc Mustache hoặc các ngôn ngữ tạo khuôn mẫu JavaScript khác"
Eddie Monge Jr

@JayPete Lợi ích của việc sử dụng Jade khi phát triển angleJS có thể vì cú pháp của Jade sạch hơn. Tuy nhiên, do kinh nghiệm của tôi, nó không giúp ích nhiều. Vì vậy, chỉ làm điều đó với html :)
Dũng Nguyễn

8

Câu trả lời được chấp nhận là hơi phiến diện và bỏ qua thực tế rằng bất kỳ thiết lập trình biên dịch trước nào cho HTML đều có công dụng tuyệt vời cho BẤT KỲ loại dự án HTML nào: Tính linh hoạt của thành phần và kết quả đánh dấu.

Làm việc một mình trên một ứng dụng góc cạnh? Hãy thử Jade.

Jade cải thiện khả năng mô-đun hóa HTML của bạn, giảm lượng thời gian bạn dành cho việc gỡ lỗi HTML và cũng khuyến khích xây dựng kho đánh dấu.

Trong thời gian thiết kế, có thể có rất nhiều lần lặp lại trên các phần HTML. Nếu đầu ra HTML dựa trên một tập hợp các tệp ngọc, nhóm sẽ dễ dàng hành động linh hoạt khi thay đổi các yêu cầu. Ngoài ra, việc thay đổi đánh dấu thông qua việc biên soạn lại jade bao gồm mạnh mẽ hơn đáng kể so với việc viết lại HTML thuần túy.

Nói như vậy, tôi nhận ra mối ác cảm chung đối với việc trộn đá góc cạnh với ngọc bích trong giai đoạn sản xuất hoặc phát triển. Giới thiệu một tập hợp kiến ​​thức cú pháp cần thiết khác là một ý tưởng tồi đối với hầu hết các nhóm và việc sử dụng ngọc bích có thể che giấu việc quản lý dự án không hiệu quả bằng cách trừu tượng hóa một số công việc sẽ bị cấm theo các nguyên tắc DRY (ví dụ: lười chuẩn bị đánh dấu)


2
Không hiểu tại sao điều này lại có -1, nhưng tôi đã phản bác lại nó.
Mark K Cowan

Nó đã bị phản đối vì nó không hoàn toàn đúng. Jade không làm bất cứ điều gì để mô-đun hóa HTML. Bạn có thể nói những điều tương tự về HTML thuần túy theo đúng nghĩa đen nếu nó được sử dụng đúng cách với trình biên dịch trước.
Justin

1
Bạn nói đúng, tất cả các trình biên dịch trước cũng vậy. Đối với Jade, Mixins jade-lang.com/reference/mixins có thể cải thiện khả năng mô-đun hóa (đặc biệt là so với HTML vani). Nếu bạn quan tâm đến việc mô-đun hóa HTML, bạn cũng có thể thích polyme-project.org .
Mirko

7

Tôi đã đọc tất cả các câu trả lời ở trên và hơi ngạc nhiên khi không ai đề cập đến một khía cạnh khiến việc sử dụng ngọc bích trong việc tạo các mẫu AngularJS trở thành một điều rất hữu ích.

Như đã nói, trong quá trình sản xuất, các kịch bản thực tế có sự khác biệt giữa việc nhập html thô và ngọc bích thực sự đáng chú ý, nhưng điều quan trọng hơn chúng ta không bao giờ nên quên là đôi khi chúng ta cần các mẫu anglejs được thay đổi động và khởi động lại .

Nói một cách đơn giản, đôi khi chúng ta cần thay đổi html qua innerHTML và sau đó buộc AngularJS phải biên dịch lại nội dung. Và đây chính xác là loại nhiệm vụ khi tạo ra những lượt xem như vậy thông qua ngọc có thể mang lại lợi ích cho nó.

Ngoài ra, AngularJS hoạt động tốt với các mô hình, cấu trúc mà theo định nghĩa là nổi tiếng. Trên thực tế, nó xảy ra rằng chúng tôi thực sự không biết cấu trúc chính xác (hãy tưởng tượng, giả sử, trình kết xuất JSON). AngularJS sẽ khá vụng về ở đây (ngay cả khi đang xây dựng một ứng dụng góc cạnh), trong khi ngọc bích sẽ thực hiện công việc.


2

Bạn có thể bao gồm các mẫu góc thông qua Jade.

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

Đối với các mẫu trong bộ nhớ đệm, tôi nhận thấy điều này ít mỏng manh hơn nhiều so với việc đưa các mẫu đã thoát vào các tệp javascript.

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


2

Jade chắc chắn gần với html hơn nhiều so với Haml. Vì vậy, việc chuyển đổi ngữ cảnh thực sự rất tối thiểu. Tuy nhiên, nó không hoàn toàn vắng mặt. Nó có thể không quan trọng đối với một nhà phát triển. Nhưng khi nhà thiết kế của bạn đến và hỏi bạn làm thế nào để thẻ lồng nhau hoạt động bình thường, bạn đang giải quyết một vấn đề không cần thiết mà bạn đã tạo ra ngay từ đầu.

HTML vẫn có thể được viết rất dễ đọc và có thể sử dụng các phần để làm cho nó dễ hiểu hơn. 500 dòng bất cứ thứ gì khó đọc - có thể là Jade hoặc HTML.

Đây là một mẫu Ngọc

.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

Và HTML tương đương

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

Khi được viết một cách dễ hiểu, tôi không thấy HTML có nhiều bất lợi đặc biệt để đảm bảo chuyển đổi. Chắc chắn, các dấu ngoặc nhọn là một chướng mắt. Nhưng tôi thà có chúng, còn hơn phải đối mặt với những nghi ngờ của nhà thiết kế rằng liệu hướng mà tôi đã giới thiệu có phá vỡ html hay không. (Có thể không. Nhưng chứng tỏ đó không phải là một nỗ lực xứng đáng)


0

Trước hết, bạn luôn cần một số kiểu tạo mẫu phía máy chủ.

Tạo khuôn mẫu phía máy khách thuần túy có những bất lợi lớn trong thời gian tải, vì vậy nó thường được giảm thiểu bằng cách hiển thị một số phần tử tĩnh trên máy chủ. Bằng cách này khi người dùng tải một phần trang, anh ta sẽ thấy một số phần tử trên trang.

Và tốt, các mẫu rất hữu ích trong trường hợp này, mặc dù đôi khi mọi người sử dụng trình tạo html tĩnh như Jekyll để thay thế.


Có một lý do khác để sử dụng Jade mà trước đây chưa được đề cập ở đây.

Khoảng trắng.

Nếu bạn đang viết HTML do con người bảo trì có thụt lề và ngắt dòng, mỗi dấu ngắt dòng sẽ dẫn đến một nút văn bản khoảng trắng. Nó có thể định dạng khá nhiều cho các phần tử nội tuyến trong một số trường hợp và làm cho mã javascript trở nên kỳ lạ hơn.

Bạn có thể đọc thêm chi tiết tại đây: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Nếu bạn đang viết mã Jade, nó được biên dịch thành HTML một dòng sẽ không gặp vấn đề này.


> [FasteRender] ( meteorhacks.com/fast-render ) là giải pháp không liên quan đến kết xuất phía máy chủ. Nó gửi dữ liệu cần thiết để hiển thị trang đầu tiên của bạn với HTML ban đầu được tải từ Meteor, vì vậy trang được hiển thị ngay sau khi JavaScript được tải đến máy khách. Nó cho kết quả giống hệt như Hiển thị phía máy chủ (SSR), nhưng vẫn gửi dữ liệu qua dây mà không vi phạm một trong các nguyên tắc cốt lõi của Meteor.
Max Hodges vào

0

Khi làm việc theo nhóm, front-end có thể thích thiết kế các trang của họ dưới dạng html tĩnh. Việc dịch html tĩnh đó thành các mẫu động là một nguồn lỗi và việc thêm ngọc sẽ thêm bước dịch như vậy.

Như nhiều người khác, tôi thích sự đơn giản!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.