Meteorでの私の経験は、選別するのが難しい何かを取り入れて始めるほど素晴らしいものではありません。 しかし、私はいくつかのことに出会い、それらについて頭を打ち、いくつかの解決策を見つけました。 また、この記事では、Meteorでヒスイを使用する際の観察/ヒントを共有します。 残念ながら、彼にとってはすべてが純粋なヒスイほどではありません。
私のプロジェクトでは、mquandalle:jadeパッケージを使用していますが、これには多くの不快な機能があります。 カスタムテンプレートヘルパーは、期待どおりに機能しません。 標準構文では、ヘルパーが単独で使用されている場合は、通常の文字列でヘルパーを取得して呼び出すだけです。 または、何かの文字列で使用されている場合は、#{}で囲みます。 次に例を示します(すべてのcoffeescriptコード):
ヘルパー:
Template.Some.helpers( ifHelper: -> return true plainTextHelper: -> return 'Just some value' )
テンプレート:
template(name='Some') if ifHelper .some-class #{someHelper}
ヘルパーに値を渡して文字列の値を取得するまで、すべて正常に機能します。 そして、これは必須であり、非常に頻繁に行われます。 #{someHelper someval}と書くと、出力は文字列 '#{someHelper someval}'を取得します。 おそらく、Jadeオプションが機能しないため、だれかがすぐに決定することになるので、標準のテンプレート構文を使用する必要があります。 しかし、たとえば、構文でネイティブでないものを使用するのは本当に好きではないので、長い間、jade構文で必要な構成を作成する方法を探し続けました。 答えはありません。 少なくとも執筆時点では、どこにもレシピは見つかりませんでした。 私は原則を犠牲にして、あまり美しくない{{someHelper someVal}}を書かなければなりませんでした。
ただし、htmlヘルパーからテキストを返す必要がある場合(そしてこれが発生する場合)、トリプル中括弧{{{someHelper someVal}}}を使用する必要があります。 それ以外の場合、htmlコードは安全です。つまり、「&コード;」の形式で表示されます。
そうでない場合の代わりに、unlessを使用する必要があります。 しかし、Meteor Editionのフリーライフでは、このテンプレートエンジンに固有の通常のjs条件はありません。 したがって、テンプレートエンジンに必要な機能を配置し、プロジェクト間でそれをドラッグするファイルを非常に迅速に作成しました。 このように見えますが:
UI.registerHelper 'print', (obj)-> console.log('TEMPLATE DEBUG: type:', typeof(obj), 'val:', obj) UI.registerHelper 'equal', (obj1, obj2)-> return obj1 == obj2 UI.registerHelper 'notequal', (obj1, obj2)-> return !(obj1 == obj2) UI.registerHelper 'collectionIsEmpty', (col)-> error_flag = false try col.fetch() catch error obj = col error_flag = true if !error_flag obj = col.fetch() return !obj.length
誰かが知らない場合、UI.registerHelper関数は、すべてのテンプレートで使用可能なグローバルヘルパーを登録します。 関数自体に関しては、最初のものはテンプレート変数をデバッグするために使用されます。 変数にあるものと、なぜ期待どおりに機能しないのかを理解することが役立つ場合があります。 書くだけ:
{{print someVar}}
...または:
{{print someHelper}}
...そして、コンソールに出力を取得し、そこでタイプと値を確認します。
2番目と3番目のヘルパーは、私のお気に入りのWebフレームワークであるDjangoのテンプレートの単純な条件を適応させています(広告なしの場所はどこですか?)
最後のヘルパーは、コレクションを反復(反復)する機能をテストするために使用されます。 コレクションから.fetch()を返したかどうか、または純粋な形式かどうかを疑わないために、ヘルパーは少し複雑です。
また、テンプレートを操作する際に、それぞれの構文について長い間苦労しました。 それぞれを呼び出すとき、テンプレートのコンテキストを変更しますが、これはテンプレートのスコープではなく、反復可能なオブジェクトのスコープを指します。
.some-class #{this.title} each MyBlogPostCollection h1 #{this.title}
前者の場合、.titleはその名前のテンプレートヘルパーか、iron-routerを使用している場合はデータオブジェクトのプロパティになります。 2番目では、.titleはMyBlogPostCollectionコレクションオブジェクトから取得されます。 ちなみに、これはプロパティを参照するように書くことはできません。非常に簡単です#{title}
しかし、それはすべて非常に簡単で、今では実際に私が戦ったものです。 それぞれで親コンテキストからオブジェクトにアクセスする必要がある場合、それが使用されます...(2ポイント)、これを記述する必要がない場合、そのパーサーはゴブアップしません。 その結果、これらは次のようになりますが、必ずしも明白な構造ではありません。
{{someHelper ../../..}}
親コンテキスト内で、必要に応じて、プロパティに直接アクセスすることもできます。 すなわち:
{{someHelper ../../title}}
また、要素のクラスを動的に配置しようとして頭を大きく叩きました。 おそらく、いくつかのものが非常に緊密に届くのは私だけです。
.contacts(class="{{#if isPdf}} border-radius-pdf {{/if}}")
ヘルパーで同じことが必要な場合は、次のようにします。
.contacts(class="{{#if isPdf}} {{border-radius-pdf someVal}} {{/if}}")
そして、はい、小さなコメント、完全なif-elseコンストラクトは次のようになります:{{#if <...>}} {{else}} {{/ if}}、つまり#はありません。見た目は論理的ではありません。
純粋な玉if-elseは単純に見えます:
if .some value else .another value
ただし、ifに条件を追加できないことに注意してください。
ヒスイを使用することの複雑さのうち、これはおそらく私が今すぐ伝えることができるすべてです。 記事を書くために座ったとき、テンプレートの操作だけでなく、フォームデータの処理、画像の読み込みでもいくつかのトリックを共有したかったのですが、ヒスイについて書いた後、すべてをヒープに捨てないことにしました。 先日、私は重要なタスクを解決しました-ユーザーデータを使用してアプリケーションのスクリーンショットを撮ることを学びました。 おそらく、これのいくつかは興味深いでしょう-要求があればコメントを残してください-私は書きます。