共有例 Vue Family Bucket 実践プロジェクト概要

フロントエンドの観点から見ると、Vue は現時点で最も理想的なフロントエンド MVVM フレームワークであると言えます。すべてがインターフェイスを提供しており、簡単に始めることができます。この記事では、Vue ファミリー バケット (Vue. +Vue-router+Vuex) を使用して jQuery+ を再構築する テンプレート プロジェクトのプロセスと期間中の成果。この記事では主に Vue ファミリーのバケット実践プロジェクトの概要 (推奨) を紹介します。編集者が非常に優れていると考えたので、参考として共有します。編集者をフォローして見てみましょう。皆さんのお役に立てれば幸いです。

はじめに

Vue を学ぶための最良のチュートリアルは他にありません。おそらく、フレームワークの作成者はデザイナーであり、バックエンドのバックグラウンドがないため、さまざまな抽象概念を使用できます。ここでは、Vue、Vue-router、および Vuex の概念について簡単に説明します。詳細については、公式ドキュメントを参照することをお勧めします。

Vue

Vue のコア機能は双方向バインディングであり、インターフェース主導のデータ変更とデータ主導のインターフェース変更を自動的に実現でき、フロントエンドのリッチな対話型アプリケーションの開発コストを大幅に削減できます。同様のフレームワークである Vue は複数ありますが、Vue の実装には、ES5 のネイティブ機能を活用することでパフォーマンスの点で一定の利点があります。

Vue-router

Vue-router は公式ルートであり、URL とコンポーネント間のマッピング関係を整理し、コンポーネントへの URL 変更に自動的に応答するために使用されるため、開発者はコンポーネントだけに集中する必要があります。開発のルーティングは、関連する些細な問題を解決するのに役立ちます。

Vuex

Vuex は、複雑なデータ フローの状況に対処するための集中データ管理モデルを提供します。たとえば、複数のコンポーネントがデータを共有しますが、独立して動作するため、同期されたデータが同期しなくなったり、JS が原因で発生したりする可能性があります。 Object オブジェクトのフックはメモリ内の同じインスタンスを指すため、元のデータが操作されると他のコンポーネントが汚染されてしまいます。このとき、より組織化されたデータ操作モード (Vuex) が必要になります。

テクノロジー選択

jQueryとの比較

Vueの基本的な概念を理解した後、それらが本当に自分のビジネスに適しているかどうかを無意識に知りたいです。必要。

まず、MVVMで解決できる問題はjQueryで解決できるのでしょうか？答えは「はい」です。フォームを送信するときに jQuery を使用して入力から値を 1 つずつ取得したことを覚えていますか?これはインターフェイス駆動型のデータです。非同期対話型関数を実行したことがある場合は、jQuery を使用してインターフェイス内のさまざまな要素に Ajax データを入力した経験があるはずです。実行できますが、フォーム検証プラグインとフロントエンド テンプレート エンジンを使用する場合でも、実行中の各ノードで検証メソッドとレンダリング メソッドを手動で呼び出す必要があるのは問題ありません。 Webサイトのページを作るのですが、ある程度要件が複雑な場合には大きな負担となります。

次に、ルーティングです。ルーティングの本質は、URL を操作することによってインターフェイスの切り替えとメンテナンスを実現することです。これは、ルーティング要件が生成される限り、実際には何の関係もありません。 、jQuery ベースのプロジェクトですら単なる再発明です。これは単なるルートですが、jQuery 時代には単一ページのアプリケーションが作成されることはほとんどありません。

Vuex は双方向バインディングに基づいて完全に拡張されており、これはデータとコンポーネントの間にブローカーを追加するのと同じであり、コンポーネントはデータを直接操作できず、操作要件をブローカーに送信することのみが可能であり、ブローカーが実装します。このようにして、多すぎる人員や多くの手が原因で発生するさまざまな予期せぬ問題が解決され、データがアプリケーションの外に移動され、特別にストアが確立されるため、コンポーネント間のデータ汚染の問題が解消されます。 jQuery ではデータを完全に手動で操作し、予期せぬ事態がまったく発生しないため、jQuery にはそのような需要はないと言えます。

適用可能なシナリオ

jQuery と比較すると、開発の観点からは、より複雑なインタラクションを伴うプロジェクトが最も適しており、コンテンツ Web サイトは最も適していません。 Web サイトの場合は、ショッピング カート ページなど、必要に応じて個別のページでローカルに使用することもできます。

もちろん、これはすべて IE8 と互換性がないという前提に基づいている必要があります。Vue を使用している 2C サイトをいくつか見たことがあるので、この点については少し混乱しています。これらのフロントエンド担当者はどのようにして上司を騙したのでしょうか?

プロジェクト分析

プロジェクトの背景

今回のリファクタリングプロジェクトは、前の会社で開発したフロントエンドコンポーネント管理システムの要件を熟知しているため、このプロジェクトをリファクタリングすることにしました。典型的な単一プロジェクトであり、適度な複雑さを持つページ アプリケーションであり、実践的な練習に適しています。

ウェブサイト構築会社のアウトソーシングでは、多くの場合、デザイナーはコンポーネントを微調整してページをつなぎ合わせてフロントエンドに配信するだけで済むことが多く、再利用可能なコンポーネントが大量に蓄積されていることがこのプロジェクトの背景にあります。理論的には、これらのコンポーネントはフロントエンドでも再利用できますが、実際にはフロントエンドに行くたびにページ全体を再実装する必要があり、多くの人的資源が無駄になります。

機能要件

このプロジェクトのアイデアは、すべてのコンポーネントを開発し、それらを管理用の統合プラットフォームに入力して、コンポーネントを選択し、表示されているものをリアルタイムでプレビューおよび調整できるようにすることです。コードがフロントエンドに渡される限り、プラットフォームは調整結果を生成します。このコード文字列を使用して、設計者によって変更されたコンポーネントを再現できます。コンポーネントの html/css/js コードをワンクリックでコピーして、コンポーネント部分のフロントエンド開発コストをゼロに近づけることができます。プラットフォームは次の機能を実装する必要があります:

1. コンポーネントの管理、分類、検索、並べ替えのサポート

2. コンポーネントの表示、コンポーネントのオンラインプレビュー/編集のサポート

3. コンポーネントのハンドオーバー、コンポーネントコードとコードの生成のサポート-ベースの再現 コンポーネントの使用統計

4. コンポーネントのさらなる最適化を促進するための統計コンポーネントの使用をサポートします

機能分析

このテクノロジースタックは柔軟性が高すぎます。利点は、やりたいことを何でもできることですが、欠点は、アイデアを明確にするのに役立たず、実行中に変更が伴うことが多いことです。

コンポーネントは、コンポーネント ライブラリと呼ばれる widgets/ フォルダーに配置されます。これはファイル操作機能のない純粋なフロントエンド プロジェクトであるため、コンポーネントの読み取りは静的な json ファイルに依存します。コンポーネント ライブラリ。コンポーネントの分類、ラベル、名前、日付などのすべての情報を含む、データ構造はおおよそ次のとおりです:

[{
 "title": "导航类",
 "list": [{
 "widget": "bread-1",
 "title": "图标面包屑",
 "tag": "面包屑/图标",
 "author": "UI",
 "date": "2015-06-04"
 }, 
 ...]
},
...]

コンポーネントは、列/番号付きの形式でコンポーネント ライブラリに保存されます。たとえば、コンポーネント bread-1 は、このコンポーネントのストレージ アドレスが widgets/bread/1/ フォルダであることを意味します。

もちろん、コンポーネントの内部ファイル構造についても、次のように合意する必要があります:

widgets
  |-bread
    |-1
      |-album.jpg   //缩略图
      |-config.json  //配置文件
      |-script.js   //脚本模板
      |-style.css   //样式模板
      `-temp.htm   //界面模板

これらの合意により、プログラムはディレクトリ ファイルを通じてすべてのコンポーネントの情報を取得し、取得、表示、コンポーネントの検索も実現できます。

コンポーネントで最も重要なのは、コンポーネントの構成可能な項目とそのデフォルト値を含む config.json ファイルです。プラットフォームは、コンポーネントを表示するときにこの構成ファイルを読み取り、構成情報に基づいて構成パネルを生成します。ここで定義できます コンポーネント インターフェイス、スタイル、スクリプトのすべての変数について、構成ファイルは次のようになります:

{
 "cssConfig": {
 "fontSize": {
  "name": "字号",
  "value": "12px",
  "type": "text"
 },
 ...
 },
 "jsConfig": {
    ...
 },
 "showConfig": {
 "viewWidth": {
  "name": "栅格宽度",
  "value": 12,
  "type": "number"
 },
 ...
 }
}

構成ファイル内の cssConfig、showConfig、および jsConfig の 3 つのブランチはコレクションです。これらの変数をコンポーネントに適用する場合は、フロントエンド テンプレート エンジンを使用する必要があるため、コンポーネントの 3 つの主要な部分は開発中にテンプレート構文で記述されます。テンプレート エンジンによる解析後、スタイルなど、実際に設定された html/css/js コンテンツを取得できます。テンプレートは次のようになります。

.widget-bread-1 {
  font-size: ${fontSize.value}; 
  color: ${textColor.value}; 
}
.widget-bread-1 a { 
  color: ${textColor.value};
}
.widget-bread-1 a:hover{
  color:${hoverColor.value};
}
.widget-bread-1 .ion { 
  font-size: ${iconSize.value}; 
  margin: 0 ${iconMargin.value};
}

コンポーネントの実際のコードを取得したら、結果を挿入するだけです。 HTML と CSS はテキスト コンテンツを直接置き換えることができます。js はモジュール形式で導入されるため、モジュール全体の名前を変更して、モジュール全体を置き換える必要はありません。なので、js モジュールの名前はランダムです。

ここで問題が発生します。一部のコンポーネントはページ内で複数回使用する必要があるため、このコンポーネントの js セレクターは、js モジュールのランダムな名前を使用することで解決できます。 ID は予約変数として使用され、この文字列はコンポーネント インスタンス内では同じですが、複数回呼び出された場合には異なります。 ${id} はコンポーネントの親ノードの ID またはクラスとして使用されるため、発生する可能性のある CSS 名の競合の問題を解決するために、コンポーネントの CSS 名前空間として使用することもできます。

上記はプロジェクトの中核となる機能です。

さらに、localStorage はスタンドアロン データ統計を実装するためのストレージ メソッドとして使用され、現在のブラウザーのコンポーネントの使用記録と各使用の構成を収集できます。これは主にローカル ストレージの操作ですが、の開発です。プロジェクト自体 フロントエンド テンプレートに加えて、最初のロード後に localStorage を使用してキャッシュされるコンポーネント テンプレートも使用されます。これらのコンテンツのキャッシュ戦略は異なります。ユーザー データは永続的に保存される必要があり、プロジェクト テンプレートは手動で更新する必要があります。状況に応じてコンポーネント テンプレートを更新する必要があります。保存されているコンテンツが多数ある場合、それらを 1 つずつ削除するのは現実的ではありません。誤って破損する可能性があります。ここでのアプローチは、localStorage 操作をカプセル化することであり、ストレージ メソッドはキーの前に追加されます。削除する場合は、ローカルに保存されたキーを調べて、それが一致するかどうかを判断するだけです。対応する値の取得メソッドでは、値を取得する前にキーのプレフィックスを逆にする必要があります。

さらに、localStorage は文字列アクセスのみをサポートしており、オブジェクト型へのアクセスを容易にするために、この変換では、値が一致したときに文字を盲目的に変換することはできません。ユーザーが実際にオブジェクト文字列を保存し、それを取り出すときにそれをそのまま戻したい場合があるため、オブジェクトは自動的にオブジェクトに変換されます。 storage メソッドは、値がオブジェクトであることを検出すると、値が文字列に変換され、その前に識別文字列が綴られますが、このメソッドはこの識別を検出した後にのみ次の文字列をオブジェクトに復元します。このプレフィックスは固定されているため、理論的には常に宝くじの当選者に遭遇する可能性があり、この問題に対する他のより良い解決策があるかどうかはわかりません。

プロジェクトの主な機能ポイントは次のとおりです。

リファクタリング

1 つのリファクタリング

最初のリファクタリングでは、Vue のみを使用しました。リファクタリングのプロセス中に最初に気づいたのは、本来はテンプレート エンジンを呼び出す必要があった作業がフレームワークによって行われるということでした。元々は js にバインドされていたイベントを、他のさまざまな構文糖とともにテンプレートに直接バインドできるようになりました。

もちろん、最も重要なことは双方向バインディングに基づいて、インターフェースとデータを自動的に関連付けることができ、プログラムがある程度の自律性を持っていると感じさせることができます。正常に動作するには、開発者は事前にすべてのステップを計画する必要がありますが、jQuery よりも自由度が低いように思えます。レンガの移動を例に挙げると、jQuery はレンガを簡単に持ち上げたり、派手な方法で移動したりできる非常に柔軟なクレーンのようなものです。Vue は、レンガを特定の場所から別の場所に移動したいと指示します。特定の場所で何が起こるかは対処方法によって異なりますが、ボタンを押すとレンガが自動的に移動します。

どちらの方法にも、それぞれ長所と短所があります。クレーンをうまく運転すれば、非常に柔軟に動作できます。欠点は、何度も運転しなければならないことです。ボタンは一度だけ自動的に実行するようにプログラムできますが、事前に道路の穴を点検し、他のすべての車のスケジュールを設定し、すべての状況を明確に説明する必要があるという欠点があります。そうしないと、車が横転したり衝突したりする可能性があります。 . jQuery から Vue に切り替えると、「行動する前に計画しなければならない」「車に乗ってから話すことはできない」という束縛感を必ず感じます。

再構築期間中の作業の大部分は、Vue インスタンスを確立し、js の隅々に散在するデータをデータに収集し、データを少しずつ操作するプロセスをメソッドに集中させ、データのフィルター処理を一元化することです。このプロセス全体は、すべての実装の詳細を明確にレビューし、各実装方法が合理的であるかどうかを検討することができ、すべての要約が完了すると、クレーンを 1 つずつ押し込むことになります。 Vue サンプルは最終プロジェクトとなり、自動的に実行できるようになります。

再構築後、Vueの各種機能に依存することで論理部分のコード量は減りましたが、それ以外にはルーティングがないため、リフレッシュの状態が失われるという問題が発生しました。ページは使用されていないため、まだ存在します。Vuex もデータ汚染の穴に遭遇しました。これはディープ コピーでのみ解決できます。また、コンポーネントベースの開発モデルにより、コード構成がより断片化されます。これらの問題は二次的な再構築を必要とします。

2 回目の再構築

2 回目の再構築の目標は、ルーティング、Vuex、コード構成、および Wild Dog Cloud バックエンドを改善することです。

1回目のリファクタリングの経験はありますが、2回目のリファクタリングの開始時点では、ルーティングとVuexのどちらを先に実装すべきか、まだ少し混乱しています。よくよく考えてみると、ルーティングが行うのは「破棄」、Vuexが行うのは「修正」のほうが、修正後の解体の作業量が少ない気がするので、Vuexを先に使います。

Vuex の概念は、いきなり理解するのは少し抽象的ですが、一度使用すると、非常に快適に感じます。また、Vuex の導入後、ルーティングと異なり、シナリオを区別せずに使用できます。データ汚染は自然に解決され、Vuex によってもたらされるアクション => ミューテーション => ストアのプロセスが受け入れられると、Vuex の導入プロセスは基本的に、データをストアに転送し、データ操作をアクション、ゲッターに分散することになります。 、突然変異、および大量の同期を同時に行うため、データ操作が必要ないため、コードの量が削減されます。

その後、ルーティングを導入し始めましたが、最初はビューを分割する方法がわかりませんでした。問題は、理論上、メイン インターフェースを細分化する必要があるかどうかです。非常に細かく分割できますが、アプリケーションの実際の使用シナリオを組み合わせると、インターフェイスの切り替えが比較的頻繁であり、コンポーネントの頻繁なロードとアンロードにより非常にコストがかかることがわかりました。さらに、密結合したコンポーネントを異なるビューに分割するには、次のことが必要になります。多くのステータス情報を記録することは価値がありませんが、最終的には諦めて記録しませんでした。メインビューは引き続き分裂しています。 3 つのビューのアクセスの重複が高くないことを考慮すると、コンポーネントを非同期でロードし、Vue 自体が非同期コンポーネントをサポートしているため、この問題は非常に簡単になります。 Promise を返すこともできるし、任意の方法でコンポーネントを取得することもできます。

次のステップは、Wild Dog Cloud に接続して、実際のユーザー管理とデータ統計を実現することです。Wild Dog Cloud を通じて、ユーザー認証やデータ保存などの一連の機能を、js のみを使用して開発できます。 。このようにして、localStorage での以前のすべての操作を Wild Dog Cloud での操作に変更する必要があり、データがクラウドに到達したときの信頼性が高まります。

これで、2 回目の再構築が完了しました。全体的なビジネス コードは大幅に減ったように感じますが、結局のところ、フレームワーク ファイルの数は 3 つ追加されていると推定されます。ファイルは元の 3 つから 2 つに減りました。モジュール化には、webpack の代わりに seajs が使用されます。なぜなら、私はまだ webpack に対して様子見の姿勢を持っており、その必要性を感じていないからです。重要なのは、Webpack に基づいて開発されたコードには多くのプライベートグッズが混在しており、それなしでは実行できないということです。もちろん、ローカル キャッシュと組み合わせた場合、seajs には webpack よりも多くの利点があります。jQuery と Vue の違いと同様に、重要なのは使用シナリオにあります。適当なのが一番です。

追記

2 つのリファクタリングの実践と落とし穴を経て、Vue フレームワークをより深く理解できました。Vue を柔軟かつ自由に使用したい場合は、開発者のプロジェクト アーキテクチャ能力が最低限必要です。 Vue を最下層に導入するには、jQuery テクノロジ スタックには含まれない、インフラストラクチャ ビルダーの計画機能に関する最小要件も必要になります。これらの制約は、開発者が独自の制約を確立するように導くプロセスでもあります。ルール システム、これは良いことであり、一般的な傾向です。結局のところ、真の自由はルールの中にのみ存在します。

この記事の完全なコードは Github にあります。

関連する推奨事項:

React Family Bucket を使用してバックエンド管理システムを構築する詳細な例

Family Bucket によって開発された Vue2.0 Web アプリケーション (Wiji APP を参照)

サンプルの詳細な説明vue複合コンポーネント実装 登録フォーム機能

以上が共有例 Vue Family Bucket 実践プロジェクト概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。