@yamato-daiwa/es-extensions(YDEE)との結合

@yamato-daiwa/frontendと言うnpmパッケージのルートディレクトリに在る Functionality.pugファイルを含むと、@yamato-daiwa/es-extensions （略：「YDEE」）の1.7バージョンの全機能（インターフェースやタイプアリアスの様にTypeScriptを JavaScriptへの変更の際存在しなく成る機能以外）が利用可能に成る。

include ../../node_modules/@yamato-daiwa/frontend/Functionality.pug

貴方のPugファイル場合、node_modulesへの相対パスが異なる可能性が有ります。

Pugプリプロセッサの必要な最低バージョン：3.0。

ウェブページの原型を使う場合、Functionality.pugファイルは既に含めてあり、再び含む行為はエラーを発生させる。

当機能が求められる主な場合は静的プレビュー作成の段階での簡易なデータモキング。例えば、下記の様にデータ（意味のない文字列でも此の段階では問題が無い）に満たされている16件のカードのマークアップを早く作成できます。

ul.ProductsList

  each index in Array.from(new Array(16).keys())

    li.ProductCard

      - const productTitle = getRandomString({ minimalCharactersCount: 6, minimalCharactersCount: 32 });

      span.ProductCard-Title= productTitle

      img.ProductCard-Photo(
        src=getRandomObjectPropertyValue(DummyImagesURIs)
        alt=`「${ productTitle }」商品の写真`
      )

      span.ProductCard-PriceLabel
        span.ProductCard-PriceLabel-Amount= getRandomInteger({ minimalValue: 1000, maximalValue: 10000 })
        span.ProductCard-PriceLabel-Currency 円

此処でgetRandomString、getRandomObjectPropertyValue、 getRandomIntegerと言うYDEEの関数が利用され、但しDummyImagesURIs 連想配列型の定数はYDFの一部。其の結果、各カードに於いて下記の様なコードHTMLコードが生成される (imgタグに於いてsrc アトリビュートの値は空間を占めすぎない様に部分的省略)。

<li class="ProductCard">

  <span class="ProductCard-Title">5XDoHI8G9qbjrvfFAq0ZrjX2KP4qcFsHzDXS9IW6nJjOnvB0FQgulYL</span>

  <img
    class="ProductCard-Photo"
    src="data:image/svg+xml;base64,PHN2ZyB4b(...)"
    alt="「5XDoHI8G9qbjrvfFAq0ZrjX2KP4qcFsHzDXS9IW6nJjOnvB0FQgulYL」商品の写真"
  >

  <span class="ProductCard-PriceLabel">
    <span class="ProductCard-PriceLabel-Amount">8301</span>
    <span class="ProductCard-PriceLabel-Currency">円</span>
  </span>

</li>

上記の様なYDEEの利用が予定されていなくても、YDFのマークアップ 関連機能の正常稼働に必要で、例えばPug混入の引数の妥当性確認をするのに使われています。

include ../../node_modules/@yamato-daiwa/frontend/Components.pug

+Badge--YDF({ value: [] })

此の様なBadgeコンポーネント（Pug混入で実装）の使い方は不正です。単一の引数のvalueプロパティの型が間違っており、もう一つの必須なプロパティが欠けています。然し、YDEEを使ってプロパティの妥当性確認が実装してある御蔭で、 PugからのHTMLへの変換がエラーで落ち、英文の中級読解程度が出来れば、説明書を読まなくてもエラーで表示された情報で不備が直せます。

よく有る質問・批判への返事

批判

と言う事は、Pugコードの中にYDEEライブラリの殆どのコードが埋めてある？やりすぎなのではないか？

回答

全ての機能に就いてやまとダイワ族のライブラリに追加される機能は、実践上 需要が発生した為だと言う事です。 YDEEとの結合に関しては、需要が過去にも、現在も有ります（活用の事例が上に論述されました）。何方かの機能の需要が今後無く成った場合、其の機能を置き換えるか、削除する場合も有ります（YDFが公開されたのは最近ですが、数年前からYDFとYDFのプロトタイプはアルファテストの利用が行われていました）。ですが、YDEEとの結合は、実践上、需要が高いままなので、YDEEとの結合の取り除きは予定されていません。

質問

サーバ側でMVCフレームワークと同時に使用する場合、YDEEコードの存在はPugからHTMLへの変換の速度に悪影響しないのか？

回答

影響を及ぼします。其れに実質が有る程度 (約2-3秒ですが、サーバ側でレスポンス生成する場合許容されない時間です)。

YDEE結合は主に静的プレビュー段階専用ですが、PugからHTMLへの変換がウェブサイト・アプリケーションの納品の前に済まされる場合、他の開発段階に使っても特に問題有りません。

又、MVCパータンを用いてサーバ側レンダリングを実装する段階でも、例えばPug混入の引数の妥当性確認（UI・UXコンポーネントの混入を含む）が動く様に、又はページの原型が使える様に、パフォーマンスの低下無しでYDEE結合を使用する方法を下記に示します。方法としては専用説明書が用意してありますが、簡単に説明すると、源Pugコードを出力HTMLコードへの２段階 変換を確保しなければいけません。 １段階目の際、中間テンプレートファイルが生成され、各ファイルが データベースからのデータの様に動的データに応じて変わりません。但し、１段階目はウェブサイト・ウェブアプリケーションの各バージョンの納品（デプロイ）の前に一度だけ行われます。 ２段階目の際、動的データが挿入され、最終のHTMLコードが生成されます。