すべては HTML コンポーネントです - HTML コンポーネント化とビジュアルプログラミングについての簡単な説明_html/css

すべては HTML コンポーネントです - HTML コンポーネント化とビジュアルプログラミングについての簡単な説明_html/css_WEB-ITnose

WBOY

リリース： 2016-06-21 08:54:02

オリジナル

1023 人が閲覧しました

AngularJS 1.0.7 以降、プロジェクトで使用します。私はちょうど angular-seed を使用してページを作成し始め、それを ng-controller と組み合わせて多くのことを実行しました。同時に、ディレクティブを使用していくつかのパブリックコンポーネントを作成しました。

私たちのグループが振り返りをしていたとき、私たちはゆっくりと比較し始めました。 ng-controller で作られたものはどれも大きく、相互に関連しており、組織が明確ではありません。ただし、ディレクティブは自己完結型であり、コンポーネントのネストと通信制御により、任意のページを作成できます。また、各コンポーネントが独立しており、テスト可能であり、他の Scope / EventListener の影響を受けないことも保証されます。

すべては指示であるべきです。

例を示します。

JavaScript

<bw-appnode appnode-restful>    <bw-table>        <bw-start-appnode></bw-start-appnode>        <bw-list></bw-list>    </bw-table>    <bw-search>    </bw-search></bw-appnode>

ログイン後にコピー

 <bw-appnodeappnode-restful>    <bw-table>        <bw-start-appnode></bw-start-appnode>        <bw-list></bw-list>    </bw-table>    <bw-search>     </bw-search></bw-appnode>

ログイン後にコピー

この単純な HTML 構造は、多くの苦労を経てまとめられました (模倣度の高いサンプル)

手がかり識別できますか？ 1. コンポーネント化 2. ビジュアル HTML 3. テスト可能なユニット

1. コンポーネント化

言うまでもなく、bw-appnode は、bw-table や bw-search と同様にコンポーネントです。これらのコンポーネントは相互にネストされており、互いに独立しており、プロトコル (スコープまたはサービス) を使用して通信します。利点は非常に明白です。

たとえば、bw-table はまだ完成しておらず、サーバーの Restful API もまだ完成していませんが、bw-search の開発を独自に開始できます。 bw-search には、bw-appnode の偽のデータをフィルタリングする独自の独立した UI と複雑なロジックが付属していますが、bw-table は単なるレンダリング層であり、bw-appnode に対する変更は自動的に bw-table に反映されます。それが角度スコープです)。

2. 視覚化/表現

理由 1: 私たちは JavaScript イベントバインディングを使用して多くの関数を実装することに慣れています。ゆっくりと、ボタンがクリックされたときに何が起こるかを推測するか、ソースコードを苦労して追跡することしかできません。 Dom ノード上に JavaScript イベントリスナーがいくつあるかを検出することは困難です。エンジニアは誰でも、JS ファイル内の任意の場所に、予測不可能でランダムなリスニングイベントをノードに追加する可能性があります。

理由 2: HTML5 で非常に多くのタグが追加される理由を覚えていますか?たとえば、セクション/記事/ビデオなどです。このため、HTML ページと関数はより視覚的でコンポーネントベースになる可能性があります。視覚化とは、何をしているのか一目でわかることを意味します (Chrome Developer Tools Inspect、Google Crawler の正確な検索)。コンポーネント化とは、ラベルが独自の一連の独立した動作とビューをレンダリングすることを意味します (Web コンポーネント / Shadow-Dom のタイトルの意味)。したがって、この HTML フラグメント/ページブロックが何をするのかを HTML から理解できれば、それがどれほど素晴らしく便利であるかがわかります。ここには記述プログラミングという別の用語もあります。この例では、最上位ノードには

JavaScript

appnode-restful

ログイン後にコピー

 appnode-restful

ログイン後にコピー

という名前の新しいディレクティブがあります。名前が示すように、これはサーバー側の情報を取得するために使用されます。のデータ。サーバーが終了する前に、静的データがそこから直接取得されます (Promisesolve を使用)。データを取得した後、それは bw-appnode のスコープに直接設定されます。

さらに意識すべき点は、このノードは別の独立したディレクティブであるため、ajax データキャッシュ処理などのより複雑なロジックを考慮できることです。私たちはこのコンポーネントに冷静にこう言いました。「とにかくこれをやって、ゆっくりとその方法を洗練させてください。望むだけ正確に実行してください。人生で 1 つのことしかやらないとしても、それができないとは思いません」上手にやれよ。」さらに、このノードは他の場所でも使用できます。appnode データが必要な場合は、この bw-appnode ページに限定されません。ただし、私はここでコンポーネントの主な目的が再利用であると言っているわけではありません。これは明らかにこの記事で話そうとしていることではありません。

3. テスト可能なユニットと jsDoc

ここで話しているのは単体テストではなく、ユニットのテストです。明らかに、上記のコンポーネントはいずれも、独立してテスト用に取り出すことができます。関連するディレクティブの js ファイルを導入して html ファイルを表示するだけで、このディレクティブを別の独立したテストスペース (分度器ドライバー) でテストできます。テストケースとデータ環境は、必要に応じて追加したり、変更したりできます。強い結合の問題を心配する必要はまったくありません。

また、jsDoc はコンポーネント化されているため、記述がはるかに簡単です。ディレクティブ、モジュール定義。

この経験をまとめてから数か月後 (すべてをディレクティブにする必要があります。)、Angular2 / React チームがこの原則の重要性を以前から認識していて、秘密裏にすべてを調整していたことがわかりました。

React/Angular2 の観点では、すべてがコンポーネントです。新しい SPA を作成する場合、最初に行う必要があるのは、作業するページをさまざまなネストされたコンポーネントに分割することです。

他の人の写真を使用して例を挙げてみましょう。

明確かつ自明です。ただし、コンポーネントを引き出した後、Scope 通信を使用するか、Publish/Subscribe Nengxin を使用するかを決定する必要があります。また、ページ (コンテナコンポーネント) を構成するスーパールーターの抽象化層 (既製のルーターを使用するのは弱すぎます) 、自分で発明したルーターを使用する必要があります)。ここではこれ以上の詳細はありません。

子供たちの靴について共有するための優れたリソースをいくつか紹介します。