Derby 0.6コンポーネントの紹介

リアクティブフルスタックjavascript derbyjsフレームワークに関する一連の（ 1、2、3、4 ）投稿を続けます。 今回はコンポーネント（格納庫のディレクティブの特定の類似物）-インターフェースを階層的に構築し、アプリケーションをモジュールに分割する優れた方法について説明します。

一般的なコンポーネント情報

Derby 0.6のコンポーネントは、別のスコープに配置されるダービーパターンです。 正しくしましょう。 このようなビューファイルがあるとします（デモでは、同じTodoリスト-TodoMVCのTo Doリストを選択しました）。



index.html

<Body:> <h1>Todos:</h1> <view name="new-todo"></view> <!--    --> <new-todo:> <form> <input type="text"> <button type="submit">Add Todo</button> </form>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Body：とnew-todoの両方：テンプレートがあります。new-todoをコンポーネントにする方法は？ これを行うには、ダービーアプリケーションに登録します。

 app.component('new-todo', function(){});
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、テンプレートを、それを担当する特定の機能と一致させることです。 どこも単純ではありません（例はまだ完全に役に立たない）。 しかし、この機能は何ですか？ ご存知のように、javascriptの関数はクラスを定義できます。 クラスメソッドはプロトタイプに配置されます。これはここで使用されます。



この例を少し拡張して、入力をリアクティブ変数にバインドし、送信時イベントハンドラーを作成しましょう。 最初に、コンポーネントがなかった場合の状態を見てみましょう。

 <new-todo:> <form on-submit="addNewTodo()"> <input type="text" value="{{_page.new-todo}}"> <button type="submit">Add Todo</button> </form>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 app.proto.addNewTodo = function(){ //... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでの欠点は何ですか：

1.詰まったグローバルスコープ（_page）

2. addNewTodo関数がapp.protoに追加されます-大規模なアプリケーションでは、麺があります。



new-todoをコンポーネントにするとどうなりますか：

 <new-todo:> <form on-submit="addNewTodo()"> <input type="text" value="{{todo}}"> <button type="submit">Add Todo</button> </form>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 app.component('new-todo', NewTodo); function NewTodo(){} NewTodo.prototype.addNewTodo = function(todo){ //     "scoped" //     ,   var todo = this.model.get('todo'); //... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それで、何が変わったのでしょうか？ まず、new-todoテンプレート内：独自のスコープ、_pageを持ち、他のすべてのグローバルコレクションはここに表示されません。 逆に、todoパスはここではローカルであり、グローバルスコープでは使用できません。 カプセル化は素晴らしいです。 第二に、addNewTodoハンドラー関数は、NewTodoクラス内にもあり、アプリの詳細が詰まることはありません。



したがって、ダービーコンポーネントはUI要素であり、その目的は特定の視覚ユニットの内部の詳細を隠すことです。 ここで注意する価値があり、コンポーネントがデータの読み込みを意味しないことが重要です。 データは、urlを処理するコントローラーのレベルでロードする必要があります。



コンポーネントが内部キッチンを隠すように設計されている場合、どのようなインターフェイスがありますか？ パラメータはどのように渡され、結果が得られますか？



パラメータは、通常のテンプレートと同じ方法で、属性を介して、また埋め込みhtmlコンテンツの形式で転送されます（これについては後で説明します）。 結果はイベントを使用して返されます。



この例の小さなデモ。 入力フィールドのクラスとプレースホルダーをnew-todoコンポーネントに渡して、入力された値をイベントで受け取ります。



index.html

 <Body:> <h1>Todos:</h1> <view name="new-todo" plaeholder="Input new Todo" inputClass="big" on-addtodo="list.add()"> </view> <view name="todos-list" as="list"></view> <new-todo:> <form on-submit="addNewTodo()"> <input type="text" value="{{todo}}" placeholder="{{@plaeholder}}" class="{{@inputClass}}"> <button type="submit">Add Todo</button> </form> <todos-list:> <!--    -->
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 app.component('new-todo', NewTodo); app.component('todos-list:', TodosList); function NewTodo(){} NewTodo.prototype.addNewTodo = function(todo){ var todo = this.model.get('todo'); //  ,     // (   ) this.emit('addtodo', todo); } function TodosList(){}; TodosList.prototype.add = function(todo){ //        //  .  ,   //       //    }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらすべてについて議論し、達成したことを見てみましょう。



新しいtodoコンポーネントは、プレースホルダーとinputClassの2つのパラメーターを取り、「addtodo」イベントを返します。todos-listコンポーネントをこのイベントにリダイレクトし、TodosList.prototype.addが処理します。 todos-listコンポーネントのインスタンスを作成するときに、asキーワードを使用してエイリアスリストを割り当てたことに注意してください。 そのため、on-addtodoハンドラーでlist.add（）を記述できました。



したがって、new-todoは完全に分離され、外部モデルでは機能しません。一方、todos-listコンポーネントはtodosリストを完全に担当します。 責任は厳密に分けられます。



ここで、コンポーネントに渡されるパラメーターについてさらに詳しく説明する価値があります。

コンポーネントインターフェース

テンプレートからコンポーネントへのパラメーターの転送を継承しているため、ほとんどの機能は類似していることに注意してください（特に明記しない限り、テンプレートの例を示します）。



ダービーhtmlファイルのテンプレート（およびコンポーネント）は関数に似ており、テンプレート自体が記述されている宣言があることに注意してください。 また、他のテンプレートからのこのテンプレートの呼び出し（おそらく複数）もあります。

＃テンプレート（コンポーネント）の宣言の構文と内容

 <name: ([element="element"] [attributes="attributes"] [arrays="arrays"])>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

要素、属性、および配列属性はオプションです。 彼らはどういう意味ですか？ 以下の例を検討してください。

要素属性

デフォルトでは、宣言とテンプレート呼び出しは次のようになります。

（到着まで）

 <!--   --> <nav-link:> <!--  $render.url   url  --> <li class="{{if $render.url === @href}}active{{/}}"> <a href="{{@href}}">{{@caption}}</a> </li> <!--     ,   Body: --> <view name="nav-link" href="/" caption="Home"></view>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを行うことは必ずしも便利ではありません。 時々、対応する名前のviewタグではなく、テンプレート名をタグ名として使用して透過的にテンプレートを呼び出したいと思います。 これが要素属性の目的です。

 <!--  ,       nav-link --> <nav-link: element="nav-link"> <li class="{{if $render.url === @href}}active{{/}}"> <a href="{{@href}}">{{@caption}}</a> </li> <!--  nav-link   ,   Body: --> <nav-link href="/" caption="Home"></nav-link>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それも可能ですか

 <nav-link href="/" caption="Home"/>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、タグの内容がないため、タグの終了部分は使用しません。 なに？

暗黙的なパラメーターの内容

テンプレートを呼び出すとき、viewタグ、または次のようなelement属性で名前が付けられたタグを使用します。

 <!--  --> <view name="nav-link" href="/" caption="Home"></view> <!--   --> <nav-link name="nav-link" href="/" caption="Home"></nav-link> <!--   --> <nav-link: element="nav-link"> <li class="{{if $render.url === @href}}active{{/}}"> <a href="{{@href}}">{{@caption}}</a> </li>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

呼び出されたときに、タグの開始部分と終了部分の間に、テキストや何らかの埋め込みHTMLなどのコンテンツを配置できることがわかります。 暗黙的なパラメーターcontentによってテンプレート内に渡されます。 contentを使用して、この例のキャプションを置き換えましょう：

 <!--  --> <view name="nav-link" href="/">Home</view> <!--   --> <nav-link name="nav-link" href="/">Home</nav-link> <!--    --> <nav-link name="nav-link" href="/"> <span class="img image-home"> Home </span> </nav-link> <!--   --> <nav-link: element="nav-link"> <li class="{{if $render.url === @href}}active{{/}}"> <a href="{{@href}}">{{@content}}</a> </li>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは非常に便利です。詳細を非表示にして、最上位コードを大幅に簡素化できます。



属性属性と配列は、これに直接関連しています。

属性属性

テンプレート内のテンプレートに転送されたhtmlコードのブロックを単一のブロックとして特定の場所に挿入するべきではないタスクを想像できます。 ヘッダー、フッター、メインコンテンツがあるウィジェットがあるとしましょう。 彼の呼び出しは次のようなものです。

 <widget> <header><--  --></header> <footer><--  --></footer> <body><--  --></body> </widget>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、ウィジェットテンプレート内には、 ヘッダー 、 フッター 、 本文の形式でこれら3つのブロックすべてを個別に挿入できる複雑なマークアップがあります。



これには、属性が必要です。

 <widget: attributes="header footer body"> <!--   --> <!--   --> {{@header}} <!--   --> <!--   --> {{@body}} <!--   --> {{@footer}} <!--   -->
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、本文ではなくコンテンツを使用することは非常に可能です。なぜなら、属性にリストされていないものはすべて（そして実際には配列にも）コンテンツに分類されるからです。

 <Body:> <widget> <h1>Hello<h1> <header><--  --></header> <footer><--  --></footer> <p>text</text> </widget> <widget: attributes="header footer"> <!--   --> <!--   --> {{@header}} <!--   --> <!--   --> {{@content}} <!--    h1  p --> <!--   --> {{@footer}} <!--   -->
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここには1つの制限があります。属性にリストしたものはすべて、内部ブロック（テンプレートに挿入された）で1回だけ発生します。 しかし、さらに必要な場合はどうでしょうか？ たとえば、ドロップダウンリストとリストアイテムの独自の実装を作成したい場合は、たくさんありますか？

配列属性

ドロップダウンリストを作成し、結果のテンプレートが次のような引数を取るようにします。

 <dropdown> <option></option> <option class="bold"></option> <option></option> </dropdown>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ドロップダウン内のマークアップは非常に複雑になります。つまり、単にコンテンツが私たちに合わないということです。 制限があるため、属性も機能しません。オプション要素は1つしか存在できません。 私たちの場合、配列テンプレート属性の使用が理想的です：

 <dropdown: arrays="option/options"> <!--   --> {{each @options}} <li class="{{this.class}}"> {{this.content}} </li> {{}} <!--   -->
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おそらくテンプレートを宣言するときに気づいたように、 'arrays = "option / options"が設定されています-以下に2つの名前を示します。



1.オプション-これは、呼び出されたときにドロップダウン内のhtml要素の名前になります

2.オプション-これはテンプレート内の要素を持つ配列と呼ばれ、この配列内の要素はオブジェクトによって表されます。オプションのすべての属性はオブジェクトのフィールドになり、その内部コンテンツはコンテンツフィールドになります。

コンポーネントソフトウェア

すでに述べたように、コンストラクター関数が登録されている場合、テンプレートはコンポーネントになります。

 <new-todo:> <form on-submit="addNewTodo()"> <input type="text" value="{{todo}}"> <button type="submit">Add Todo</button> </form>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 app.component('new-todo', NewTodo); function NewTodo(){} NewTodo.prototype.addNewTodo = function(todo){ var todo = this.model.get('todo'); //... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンポーネントには、コンポーネントの寿命のある時点で呼び出される事前定義関数があります。これは作成と初期化であり、「破棄」イベントもあります。 また、非常に便利です。

＃初期化

init関数は、コンポーネントをレンダリングする前に、クライアントとサーバーの両方で呼び出されます。 その目的は、コンポーネントの内部モデルを初期化し、デフォルト値を設定し、必要なリンクを作成することです（参照）。

 //   https://github.com/codeparty/d-d3-barchart/blob/master/index.js function BarChart() {} BarChart.prototype.init = function() { var model = this.model; model.setNull("data", []); model.setNull("width", 200); model.setNull("height", 100); // ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

＃作成

コンポーネントのレンダリング後にクライアント上でのみ呼び出されます。 イベントハンドラーの登録、クライアントライブラリのコンポーネントへの接続、データの変更のサブスクライブ、コンポーネントのリアクティブ関数の起動などに必要です。

 BarChart.prototype.create = function() { var model = this.model; var that = this; // changes in values inside the array model.on("all", "data**", function() { //console.log("event data:", arguments); that.transform() that.draw() }); that.draw(); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

＃イベント「破棄」

コンポーネントが破棄されたときに呼び出され、最終アクションに必要です。setIntervalなどの無効化、クライアントライブラリの無効化など。

 MyComponent.prototype.create = function(){ var intervalId = setIterval myFunc, 1000 this.on('destroy', function(){ clearInterval(intervalId); }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでコンポーネントハンドラで利用できるものは何ですか？

これに含まれるすべてのコンポーネントハンドラーでは、モデル、アプリ、dom（initを除く）、dom要素へのすべてのエイリアス、コンポーネント内で作成されたコンポーネント、parent-componentへのparent-referenceなどが使用できますコンポーネントコンストラクター関数のプロトタイプ。



このモデルは、特定のスコープを使用しています。 つまり、derbyのグローバルスコープにアクセスする必要がある場合、this.model.rootまたはthis.app.modelを使用する必要がある場合、this.modelを介してコンポーネントはコンポーネント自体のモデルのみを参照します。



アプリですべてが明確になりました。これはダービーアプリケーションのインスタンスです。たとえば、次のように、やることがたくさんあります。

 MyComponent.prototype.back = function(){ this.app.history.back(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

domを介して、ハンドラーをDOMイベントにアタッチできます（一度、removeListener関数が使用可能になります）。次に例を示します。

 //  https://github.com/codeparty/d-bootstrap/blob/master/dropdown/index.js Dropdown.prototype.create = function(model, dom) { // Close on click outside of the dropdown var dropdown = this; dom.on('click', function(e) { if (dropdown.toggleButton.contains(e.target)) return; if (dropdown.menu.contains(e.target)) return; model.set('open', false); }); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例を完全に理解するには、this.toggleButtonとthis.menuが、テンプレートで次のように定義されたDOM要素のエイリアスであることに留意する必要があります。



こちらをご覧ください： github.com/codeparty/d-bootstrap/blob/master/dropdown/index.html#L4-L11



すべてのdom：一度、removeListeners関数は、type、[target]、listener、[useCapture]の4つのパラメーターを取ることができます。 ターゲット-ハンドラーがハングアップする（削除される）エレメント;ターゲットが指定されていない場合、ドキュメントと同じです。 残りの3つのパラメーターは、通常のaddEventListener（type、listener [、useCapture]）の対応するパラメーターに似ています



テンプレート内のdom要素のエイリアスは、asキーワードを使用して設定されます。

 <main-menu:> <div as="menu"> <!-- ... --> </div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 MainMenu.prototype.hide = function(){ //   $(this.menu).hide(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンポーネントをアプリケーションから別のモジュールに削除する

これに先立って、テンプレートがアプリケーションのhtmlファイル内に既にあるコンポーネントのみを検討しました。 コンポーネントをアプリケーションから完全に分離する必要がある場合（通常は必要な場合）、次のようにします。



コンポーネント用に別のフォルダーが作成され、js、html、cssファイルがその中に配置されます（スタイルファイルには小さな機能があります）。コンポーネントは、1つのパラメーターのみが渡されるapp.component関数を使用してアプリケーションに登録されます-コンストラクター関数。 このようなもの：



app.component（require（ '../ components / dropdown'））;



以前、アプリケーションのhtmlファイルにコンポーネントテンプレートが既に存在していた場合、登録が異なることに注意してください。



app.component（ 'dropdown'、Dropdown）;



例を見てみましょう：



tabs / index.js

 module.exports = Tabs; function Tabs() {} Tabs.prototype.view = __dirname; Tabs.prototype.init = function(model) { model.setNull('selectedIndex', 0); }; Tabs.prototype.select = function(index) { this.model.set('selectedIndex', index); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

tabs / index.html

 <index: arrays="pane/panes" element="tabs"> <ul class="nav nav-tabs"> {{each @panes as #pane, #i}} <li class="{{if selectedIndex === #i}}active{{/if}}"> <a on-click="select(#i)">{{#pane.title}}</a> </li> {{/each}} </ul> <div class="tab-content"> {{each @panes as #pane, #i}} <div class="tab-pane{{if selectedIndex === #i}} active{{/if}}"> {{#pane.content}} </div> {{/each}} </div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下の行に特に注意してください。

 Tabs.prototype.view = __dirname;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここから、ダービーはコンポーネントの名前を取得します（「index：」はそこで使用されるため、テンプレート自体にもありません）。 アルゴリズムは単純です-パスの最後のセグメントが取得されます。 _dirnameが「/ home / zag2art / work / project / src / components / tabs」に等しくなったとします。つまり、他のテンプレートでは、このコンポーネントは「tabs」を介してアクセスできます。

 <Body:> <tabs selected-index="{{widgets.data.currentTab}}"> <pane title="One"> Stuff'n </pane> <pane title="Two"> More stuff </pane> </tabs>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコンポーネントとアプリケーションの接続は、次のとおりです。

 app.component(require('../components/tabs'));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

www.npmjs.org/package/d-d3-barchartのように、コンポーネントを個別の npmモジュールとして設計すると非常に便利です。