AngularJsアプリを作成するときのJadeまたはHandlebarの使用方法


120

私はjavascriptのフルスタックアプリケーション全体に新しい(しっとり)ので、Angularにはまったく新しいので、誰かがここで直接記録を付けてくれることを望んでいました。

AngularJSを使用してクライアント側のアプリを作成するときに、JadeやHandlebarsなどのテンプレートフレームワークを使用する必要があるのはなぜですか。

私はこれらのテンプレートフレームワークのいずれも使用したことがないことを言っておく必要があります。だから私はその利点に完全に精通していません。しかし、たとえばハンドルバーを見ると、ループなど、Angularで行うのと同じことの多くを実行します。

私の知る限り、Angularで適切なHTMLを使用してテンプレートを作成し、すべてのテンプレートクライアント側を実行し、これを、たとえばノードやmongoを使用するAPIの最初のアプローチと組み合わせるのが最も理にかなっています。

この混乱の理由は、GitHubで見つけた例の多くがJadeを使用しており、私には直観に反しているように見えるためです。

私を啓発して、私をまっすぐにしてください。私が知っている以上のことを知っている人からいくつかのベストプラクティスを学びたいです。

ありがとう

回答:


61

Angular環境で間違いなく Jadeを支持する人々は、OPがコメントしたように、ビューロジックがクライアントに属し、ビジネスロジックがサーバーに属していることを理解できません。

あなたがそうする正当な理由がない限り、それを行わないでください。エンジニアリングでは、可動部品が少ないシステムの方が信頼性の高いシステムであり、インターフェースの境界(クライアント/サーバー)が尊重されるシステムは長期にわたって維持しやすいため、デフォルトで最も単純なアーキテクチャにして、可能な場合は分業をきれいにします。優先する理由がある場合は、必要なことを実行しますが、注意を払う必要があります。

最近、単純性を維持するだけで、ストレートAngularテンプレートがJadeでのミキシングよりもはるかに優れたコードをいくつかレビューしました。

テンプレート拡張を除いて、ジェイドはAngularがまだ提供していない価値のあるものをテーブルにもたらします。正直に言うと、「継承よりも好意的な構成」(つまり、パーシャル)の健全な原則を使用すると、テンプレートの拡張性は必要ありません。JadeはHTMLほど「解析が簡単」ではありません。彼らはあるが、自明最高の回避-ジェイドは、間接の別のレベルを追加しながら、異なります。

サーバー側のテンプレートには、1つの有効な特殊なケースがあります。最適化。時期尚早の最適化は一般的に悪いことであることを思い出してください。パフォーマンスが本当に問題であり、これを処理するために余裕のあるサーバー容量がある場合は、サーバー側のテンプレートが役立ちます。これは、TwitterやBasecampなどの製品に当てはまります。この場合、サーバー側の多くの作業を行うコストは、サーバーへの要求が削減されることによって相殺されます。

ハンドルバーについては、AngularJSの(すばらしい)クライアント側テンプレートを置き換える必要はありません。


4
こんにちはニック、それも私が到達した答えです。私はそれをそれほど率直に述べていませんでしたが、同意します!
ジェイ・ピート

60
@ Nick、XML / HTMLを書いたり読んだりすることを楽しむ人はあまり見かけません。あなたは、ジェイドのようなより乾燥していてよりクリーンなものを支持することを実際に主張している、私が今まで見た中で最もまれな人でしょう。ライブラリはたくさんありますが、その目的は、人々がXML / HTMLの作成/読み取りから解放されることです。
Alex K

12
必要のない複雑さは紹介しません。Cコードまたはそれ以上のC ++テンプレートを読んで日々を過ごすと、HTMLを精神的に解析することは非常に簡単なことであることすぐに気付くでしょう。
エンジニア

35
「専門家がこれを主張するのは可笑しい。」、「精神的にHTMLを解析することは、実に取るに足らないことです。」私はこれらの非常に質の悪いコメントを見つけます。構文解析が非常に簡単なため、アセンブリを作成しますか?Jadeは、基本的に、AngularをXMLで使用する場合のYAMLです。
Philipp Gayret 2014

7
@NickWiggillに同意します。JADEテンプレートと未加工のHTMLを精神的に解析するには、同じ「ウェットウェア」CPU時間を必要とします。あなたが同意しない場合、私はあなたが専門家ではないと言うまでは行きませんが、私にとっては同じことです。@ Philipp、アセンブリへのC / C ++の解析がJADEからHTMLへの解析に等しいことのアナロジーは貧弱であり、ほぼリアルタイムでアセンブリの解析を開始できる人がいるとしても、ほとんどありません。開発者は、JADEと同じくらい簡単に、または非常に簡単にHTMLを解析できます。
nomis 2014

63

私はプレーンHTMLを書くのが嫌いなため、Jadeを使用してAngularJSが使用するテンプレートを生成します。それは次のようになります:

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

…プレーンHTMLよりもずっとクリーンだと思います。


12
わかりました、それであなたはあなたがプレーンHTMLを書くのが好きではないのでそれを使うだけですか?それがジェイドの主なメリットですか、それ以外のメリットはありますか?JadeはHTMLをなんらかの方法で壊してしまうので、特定の出力を取得するにはHTMLを微調整する必要がありますか?実際に必要とせずに間接層をもう1つ追加する危険性があると思います。しかし、それでも私が尋ねているのはそのためです。ここでその価値を理解したい。
ジェイ・ピート

1
実際に私はAngularに行く前にJadeから始めたので、意識的な選択というよりは行き詰まった習慣がありましたが、今のところうまくいきました。Jadeで私が持っている唯一の問題は、空白の処理方法です(私はpretty = falseを使用しています)。そのため、タグの間にスペースを追加する必要があるときはいつでも、ソースファイルの末尾の空白になってしまいました。インクルードやミックスインなどの機能がとても便利だと思いました。
thatmarvin 2013

ng-inlude一緒に使用する可能性があるは、ng-srcJadesのミックスインやインクルードとは大きく異なりますか?
ジェイ・ピート

2
HTMLの上に抽象化の@JayPeteジェイドの層があるサイコー薄いです。これは、これまでに使用した構文間の最も直感的な翻訳の1つです。Jadeでは、(テンプレートエンジンの場合と同じように)変数と条件付きロジックで掘り下げ始める場合を除いて、魔法はほとんど発生しません。実際にはそれほど違いはありません。
Chev

6
シンプルは主観的です。
シェフ、2015

46

私は正直に言って、なぜ人々がこれの違いを気にするのか理解していません:

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

それを除いて、私がもう少し人間が読めるものを見つけました。やや。なぜ人々はトピックについて熱心であるのか分かりません。それはすべてバイクシェディングです。違いはごくわずかで、有能なプログラマであれば、Googleで5秒後に簡単に翻訳できます。あなたが望むものを使って、他の誰もが何も口論しないようにしましょう。あなたの戦いを選んで、原子炉のように、実際に重要なことについての議論に参加してください;)


2
同意しますifが、方程式にジェイドを1つ追加すると、すべてが突然変化します。上記の「プレミアムユーザー」を参照してください。
TWiStErRob 2014

15
9行のHTMLページは完全に非現実的です。私が表示しているページのソースを取得すると、2320行が1580行に変換されます(html2jadeを使用)。すべてのstackoverflowテンプレートを作成した人にとって、700行以上の時間を無駄にしています
Philipp

2
@TWiStErRob jadeからHTMLに移行する場合は、テンプレートをレンダリングするだけで済みます(笑)。あなたが持っている場合はif、あなたのヒスイのマークアップでSを、あなたはすでにとにかくテンプレートエンジンのいくつかの種類を必要としている、あなたは何に変換する必要があるだろうifというエンジンによって使用される構文。私はあなたの批判を本当に理解していません。
シェフ、2014

この全体の議論が条件付きロジックが属する場所(サーバーまたはクライアント)に関するものである場合、私は当初よりも愚かな議論であると思います。両方の場合があり、どちらか一方が機能するか、どちらが使用するかが個人の好みに応じて使用します。私は私がきたよりも、これらのような引数を持つ多くの時間を費やしてきたこれまでのサーバー側のビューまたはその逆に、いくつかのロジックを置くために過去の決定をのろい過ごしました。効率性について議論したい場合は、代わりにこの会話全体のメリットについて話し合う必要があります。
Chev

3
@フィリップ、削除された行のほとんどが単に閉じタグであると想定しても安全ではありませんか?ほとんどのエディターは、開始タグを作成するときに自動的に終了タグを追加するので、700行の書き込みを実際に節約したとは思えません。
セミコロン2014年

14
  1. 独自のテンプレートエンジンを備えているため、AngularJSでハンドルバーを使用する必要はありません。
  2. 彼らがJadeを使用する理由は、htmlにコンパイルされ、後でフロントエンドでangularJSによって提供される単なるサーバーレンダラーだからです。

したがって、TL; DR、サーバーでは、任意の言語[jade、haml、...]を使用してアプリケーションのhtml構造のみを生成できます。これは、angularJSとは何の関係もありません。フロントエンドのランタイム。

サーバーでJadeを使用する必要はありません。新しい開発者を混乱させるため、使用しないことをお勧めします。クリーンで使い慣れているという理由だけでJadeを使用しているプロジェクトでは、angularJSで使用する場合、ロジックなしでプレーンHTMLを生成するのが唯一の仕事です。


2
サーバーが生成したhtmlを使用せず、ロジックとビューを完全に分離するほうがきれいではないでしょうか。または私が見逃しているものはありますか?AngularJSアプリを作成するとき、なぜJadeが良いアイデアなのですか?
ジェイピート

angularJSで使用するのは良い考えではないと私は言います。JadeはangularJSとは何の関係もありません。これを明確にするために、回答を更新します。
Dzung Nguyen 2013

ジェイドはAngularとは何の関係もないことを理解しています。AngularJSパーシャルで実際のHTMLを書き出すのではなく、Jadeの価値を理解しようとしています。多くの人々がそれを使用しているのを見て、その理由を理解したいと思います:-)
Jay Pete

2
ここでも、JadeはAngularJSとは何の関係もありません。AngularJSはHTMLパーシャルを消費し、HTMLページから提供されます。JadeやHamlなど、サーバーサイドでHTMLページを作成するために何でも使用できます。Jade / Hamlは実際にはテンプレートフレームワークではありません。彼らはより多くのプリプロセッサです。正しい質問は、「ハンドルバー、口ひげ、またはその他のJavaScriptテンプレート言語」です
Eddie Monge Jr

@JayPete angularJSを開発するときにJadeを使用する利点は、Jadeの構文がより明確であるためです。しかし、それでも、私の経験上、それはあまり役に立ちません。したがって、htmlでそれを実行するだけです:)
Dzung Nguyen 2013

8

受け入れられた答えはやや一方的なものであり、HTML用のプリコンパイラーの設定は、あらゆる種類のHTMLプロジェクト(合成とその結果のマークアップの柔軟性)に大いに役立つという事実を無視しています。

角度のあるアプリで一人で作業していますか?ジェイドを試してみてください。

Jadeは、HTMLをモジュール化する機能を向上させ、HTMLのデバッグに費やす時間を減らし、マークアップインベントリの構築を促進します。

設計時に、HTMLパーツの繰り返しが非常に多くなる可能性があります。HTML出力が一連のjadeファイルに基づいている場合、チームは変化する要件に柔軟に対応できます。また、jadeインクルードを再構成してマークアップを変更する方が、純粋なHTMLを再作成するよりもはるかに堅牢です。

そうは言っても、私は生産段階または開発段階でアンギュラとジェイドを混ぜることに対する一般的な嫌悪を認識しています。必要な構文知識のセットを導入することは、ほとんどのチームにとって悪い考えであり、翡翠の使用は、DRYの原則によって禁止される作業(たとえば、マークアップの準備に怠惰)を抽象化することにより、非効率的なプロジェクト管理を隠す可能性があります。


2
なぜこれが-1だったかはわかりませんが、私はそれを打ち消しました。
Mark K Cowan

完全に真実ではないため、反対票が投じられました。JadeはHTMLをモジュール化するために何もしません。プレコンパイラで正しい方法で使用すれば、プレーンHTMLについて文字通り同じことが言えます。
ジャスティン2015年

1
そうです、すべてのプリコンパイラについて同じことが言えます。Jadeの場合、 Mixins jade-lang.com/reference/mixinsはモジュール化を改善できます(特にバニラHTMLと比較して)。HTMLのモジュール化に興味がある場合は、Polymer-project.orgもお勧めです。
ミルコ

7

私は上記のすべての回答を読みましたが、AngularJSテンプレートの生成よりもjadeを使用することを非常に便利なものにする誰も言及していなかったことに少し驚いていました。

すでに述べたように、本番環境では、生のhtmlとjadeのタイプの現実的なシナリオの違いが実際に顕著ですが、忘れてはならないより重要なことは、動的に変更して再初期化する必要がある場合があることです環境で angularjsテンプレートです。

簡単に言うと、時々 innerHTMLを介してhtmlを変更してから、AngularJSにコンテンツを再コンパイルさせる必要ががあります。そして、これはまさに、ヒスイを介してそのようなビューを生成することが利点をもたらすことができるタスクのタイプです。

また、AngularJSはモデルとうまく連携します。モデルの構造は、定義によってよく知られています。実際、実際には正確な構造がわからないことがあります(たとえば、JSONレンダラーを想像してください)。AngularJSはここでは(角のあるアプリを構築している場合でも)かなり不器用ですが、jadeはその役割を果たします。


2

Jadeを介して角度テンプレートを含めることができます。

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

テンプレートをキャッシュする場合、私はこれを、エスケープされたテンプレートをJavaScriptファイルに含めるよりもはるかに脆弱ではないと考えています。

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


2

Jadeは、Hamlと言うよりも、htmlにかなり近いです。したがって、コンテキストの切り替えは実際には非常に最小限です。しかし、それは完全に欠落しているわけではありません。開発者にはまったく関係ないかもしれません。しかし、設計者が来て、ネストされたタグを適切に機能させる方法を尋ねると、そもそも作成した不要な問題を解決していることになります。

HTMLは依然として非常に読みやすく記述でき、パーシャルを使用してわかりやすくすることができます。500行の何かは、JadeであれHTMLであれ、読みにくいものです。

これが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

そして同等の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が特に不利になるとは思わない。案の定、山かっこは目障りです。しかし、私が紹介した間接的な方法がHTMLを壊しているかどうかについてのデザイナーの疑問に対処する必要があるよりも、むしろ私はそれらを持っています。(そうでないかもしれません。しかし、それを証明することは価値のある努力ではありません)


0

まず最初に、常に何らかのサーバー側のテンプレートが必要です。

純粋なクライアント側のテンプレートには、読み込み時間に大きな欠点があるため、サーバーにいくつかの静的要素をレンダリングすることで軽減されることがよくあります。このようにして、ユーザーがページを部分的にロードすると、ページ上のいくつかの要素がすでに表示されます。

また、この場合はテンプレートが便利ですが、代わりにJekyllのような静的htmlジェネレーターが使用されることもあります。


ここで前に触れられていないジェイドを使用する別の理由があります。

空白。

インデントと改行を含む人間が管理可能なHTMLを記述している場合、すべての改行は空白のテキストノードになります。場合によっては、インライン要素のフォーマットをかなりねじ込んで、JavaScriptコードをより奇妙にすることができます。

詳細については、こちらをご覧ください。 https //developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOMをご覧ください。

Jadeコードを記述している場合は、この問題のない1行のHTMLにコンパイルされます。


> [FasteRender](meteorhacks.com/fast-render)は、サーバー側のレンダリングを含まないソリューションです。最初のページをレンダリングするために必要なデータをMeteorからロードされた初期HTMLで送信するため、JavaScriptがクライアントにロードされた直後にページがレンダリングされます。Server Side Rendering(SSR)と同じ結果が得られますが、Meteorのコア原則の1つを壊すことなく、ネットワーク経由でデータを送信できます。
Max Hodges

0

チームで作業する場合、フロントエンドはおそらく、静的なhtmlとしてページを設計することを好みます。その静的なHTMLを動的なテンプレートに翻訳することはエラーの原因であり、翡翠を追加するとそのような翻訳ステップが追加されます。

他の多くの人と同じように、私はシンプルさを好みます!

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.