Polymer Web App を開発する際に尊重すべきベスト プラクティスに関する質問があります。
Todo アプリがあるとします。メイン要素my-main-taskは、これらの要素間の切り替えを担当します:listすべてのタスク、view単一のタスク、タスクの作成、newタスクeditとdeleteタスク。
私の質問は次のとおりです。要素は、またはnewを使用してデータを保存するか、それを?に委譲する必要があります。firebase-documentiron-ajaxmy-main-task
最近の Polymer Summit (London 2016) では、遅延(遅延読み込みなど)について多くの話題がありました。これは、必要なものだけをロード/レンダリングし、(最良の場合) 他に何もないことを意味します。
これは、あなたの質問に対する簡単な答えは次のとおりです。new要素は、データを保存するのに最も適切な場所であるため、それ自体でデータを保存する必要があります。
長い回答になりますが、しばらくお待ちください。
Google Developers の Web Fundamentalsページには、実際にThe App Shell Modelという名前のアーキテクチャ パターンがあります。このパターンは実際にあなたのmy-main-task要素を表しています。
いくつかの有用な引用：
アプリの「シェル」は、ユーザー インターフェイスを強化するために必要な最小限の HTML、CSS、および JavaScript です /.../
/.../ 一般に、アプリは可能な限り単純なシェルをロードする必要がありますが、最初のダウンロードで十分な意味のあるページ コンテンツを含める必要があります。
そうは言っても、新しいアイテムを保存するためのロジックを app shell 要素 (あなたの場合はmy-main-task要素) に入れるのは賢明ではありません。
さらに先に進むために、Polymer のサンプルShop アプリ( Github repo、 Online demo ) を見てみましょう。
「アプリ シェル」要素shop-app(ソース コード) を見ると、以下のみが実装されていることがわかります。
この特定のケースでは、すべてのページで使用されるため、カートのデータとロジックは shell 要素に配置されますが、それ以外の場合、他のビジネス ロジックはそこに実装されません。
あなたの質問に対する長い回答についてはshop-checkout、チェックアウト ページ、つまり要素 (ソース コード)を見てみましょう。フォームに関連するすべてのデータ (つまり、サーバーへの投稿) はこの要素内で行われ、app shell 要素には何も委任されていないことがわかります。
もう 1 つの例はshop-list要素 ( source code ) です。繰り返しになりますが、この要素はそれ自体でデータを取得し、セクションを変更するためにアプリ シェル要素のみと対話することがわかります。
結論として、前述の Shop アプリにも含まれている別の優れたプラクティスを挙げましょう。これは、アプリ内でデータが流れる方法です。これに関して、Polymer Summit ( Youtube ビデオ)で興味深い話がありましたが、その要点は次のとおりです。一方向のデータ バインディングを可能な限り使用し、本当に必要でない限り双方向のデータ バインディングを避けるようにしてください。これを実現するには、下向きのデータ フロー (親から子へ) を一方向のデータ バインディングとして実行し、上向きのデータ フロー (子から親へ) をイベントとして実行する必要があります。要素間の結合がはるかに低いため、これは要素の再利用に不可欠です。