今回は、Vue ファミリーバケットプロジェクトを実践的に詳しく説明します。Vue ファミリーバケットを使用してプロジェクトを実装する際の注意事項を紹介します。
フロントエンドの観点から見ると、Vue は現時点で最も理想的なフロントエンド MVVM フレームワークであると言えます。この記事では、Vue ファミリー バケットの使用方法を記録します。 Vue+Vue-router+Vuex) を使って jQuery を再構築する +template プロジェクトのプロセスと期間中の成果。
はじめに
Vue の公式ドキュメントは、Vue を学ぶのに最適なチュートリアルです。おそらく、フレームワークの作成者は設計出身でバックエンドの経験がないため、さまざまな抽象的な概念が Vue でのみ説明されています。 Vue、Vue-router、および Vuex の概念を簡単に紹介します。包括的な学習については、公式ドキュメントを参照することをお勧めします。
ビュー
Vue の中核機能は双方向バインディングであり、これによりインターフェイス主導のデータ変更とデータ主導のインターフェイス変更が自動的に実現され、フロントエンドのリッチな対話型アプリケーションの開発コストを大幅に削減できます。同様のフレームワークである Vue は複数ありますが、Vue の実装には、ES5 のネイティブ機能を活用することでパフォーマンスの点で一定の利点があります。
Vueルーター
Vue-router は公式ルートであり、URL とコンポーネント間のマッピング関係を整理し、コンポーネントへの URL の変更に自動的に対応するために使用されます。そのため、開発者はコンポーネントの開発のみに集中する必要があり、ルーティングは関連する問題の解決に役立ちます。些細な質問。
Vuex
Vuex は、複雑なデータ フローの状況に対処するための一元的なデータ管理モデルを提供します。たとえば、複数のコンポーネントがデータを共有しますが、独立して動作するため、同期されたデータが同期しなくなったり、オブジェクト オブジェクトのフックが原因で発生したりする可能性があります。 js メモリ内の同じインスタンスを指すと、元のデータが操作されると他のコンポーネントが汚染されます。このとき、より組織化されたデータ操作モード (Vuex) が必要になります。
技術選定
jQueryとの比較
Vue の基本的な概念を理解した後は、無意識のうちにそれらを jQuery テクノロジー スタックと比較し、これらが自分のビジネスに本当に必要なのかどうかを考えます。
まず、MVVMで解決できる問題はjQueryで解決できるのでしょうか？答えは「はい」です。フォームを送信するときに jQuery を使用して入力から値を 1 つずつ取得したことを覚えていますか?これはインターフェイス駆動型のデータです。非同期対話型関数を実行したことがある場合は、jQuery を使用してインターフェイス内のさまざまな要素に Ajax データを入力した経験があるはずです。実行できますが、フォーム検証プラグインとフロントエンド テンプレート エンジンを使用する場合でも、実行中の各ノードで検証メソッドとレンダリング メソッドを手動で呼び出す必要があるのは問題ありません。 Webサイトのページを作るのですが、ある程度要件が複雑な場合には大きな負担となります。
次に、ルーティングです。ルーティングの本質は、URL を操作することによってインターフェイスの切り替えとメンテナンスを実現することです。これは、ルーティング要件が生成される限り、実際には何の関係もありません。 jQuery ベースのプロジェクトはルートを再作成しているだけです。jQuery 時代には単一ページのアプリケーションがほとんど作られていないだけです。
Vuex は完全に双方向バインディングの拡張に基づいており、これはデータとコンポーネントの間にブローカーを追加することに相当します。コンポーネントはデータを直接操作できませんが、操作要件をブローカーに送信することしかできず、ブローカーが実装します。この操作では、多すぎる人員と多すぎる人手が原因で発生するさまざまな予期せぬ問題を解決するために、データがアプリケーションの外に移動され、コンポーネント間のデータ汚染の問題を排除するために特別にストアが設立されました。 jQuery ではデータを完全に手動で操作し、予期せぬ事態がまったく発生しないため、jQuery にはそのような需要はないと言えます。
該当するシナリオ
jQuery と比較すると、開発の観点からは、より複雑なインタラクションを伴うプロジェクトが最も適しており、個別のページのニーズがある場合は、Vue の適用可能なシナリオが最も適していません。 Web サイトでは、ショッピング カート ページなどを部分的に使用することもできます。
もちろん、これはすべて IE8 と互換性がないという前提に基づいている必要があります。一部の 2C サイトが Vue を使用しているのを見たので、この点については少し混乱しています。どうやってこれらのフロントエンド担当者が上司を騙したのでしょうか。
プロジェクト分析
プロジェクトの背景
今回のリファクタリング プロジェクトは、以前の会社で開発したフロントエンド コンポーネント管理システムであり、要件をよく知っているため、このプロジェクトをリファクタリングすることにしました。これは、適度な複雑さを持つ典型的なシングルページ アプリケーションであり、より使用に適しています。実践的な演習として。
このプロジェクトの背景には、Web サイト構築会社のアウトソーシングでは、多くの場合、デザイナーがコンポーネントを微調整してページをつなぎ合わせてフロントエンドに提供するだけで済むことが多く、再利用可能なコンポーネントが大量に蓄積されていることが挙げられます。理論上、これらのコンポーネントはフロントエンドでも再利用できますが、実際にはフロントエンドのページ全体を毎回再実装する必要があり、多くの人的資源が無駄になります。
機能要件
このプロジェクトのアイデアは、すべてのコンポーネントを開発し、それらを統合プラットフォームに入力して管理できるようにすることです。設計者はプラットフォームにアクセスしてコンポーネントを選択し、表示されているものをリアルタイムでプレビューおよび調整できます。コードがフロントエンドに渡される限り、プラットフォーム上でこのコード列を使用して、デザイナーが変更したコンポーネントを再現することができます。また、コンポーネントの html/css/js コードをワンクリックでコピーして、プロジェクトにすぐに適用できます。コンポーネント部分のフロントエンド開発コストはほぼゼロです。プラットフォームは次の機能を実装する必要があります:
コンポーネントの管理、分類、検索、並べ替えのサポート
コンポーネントの表示、コンポーネントのオンライン プレビュー/編集のサポート
コンポーネントのハンドオーバー、コンポーネント コードの生成とコードに基づくコンポーネントの再現のサポート
機能分析
最初のバージョンは、jQuery + テンプレートを使用して実装されました。この技術スタックは、必要なことを簡単に実行できるという点で利点があります。欠点は、アイデアを明確にするのに役立たないことです。やっているうちに変化が伴うこともよくあります。
コンポーネントはコンポーネント ライブラリと呼ばれる widgets/ フォルダーに均一に配置されます。これはファイル操作機能のない純粋なフロントエンド プロジェクトであるため、コンポーネントの読み取りは静的な json ファイルに依存します。コンポーネント ライブラリには、カテゴリ、タグ、名前、日付などのすべての情報が含まれており、データ構造はおおよそ次のとおりです:
[{
"title": "导航类",
"list": [{
"widget": "bread-1",
"title": "图标面包屑",
"tag": "面包屑/图标",
"author": "UI",
"date": "2015-06-04"
},
...]
},
...]コンポーネントは、列/番号付きの 2 次フォルダーの形式でコンポーネント ライブラリに保存され、コンポーネント コードとして保存ディレクトリを使用することが合意されています。たとえば、コンポーネントのパン-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"
},
...
}
}コンポーネントの実際のコードを取得したら、その結果をページに挿入し、適切なタイミングで更新するだけです。js はモジュール形式で導入されるため、モジュールのコンテンツのみが置き換えられます。モジュールはオーバーロードされません。モジュールの名前を変更した後はモジュール全体を置き換える必要があるため、js モジュールの名前はランダムになります。
ここで問題が発生します。一部のコンポーネントはページ上で複数回使用する必要があるため、このコンポーネントの js セレクターは、js モジュールのランダムな名前を使用することで解決できます。 id はコンポーネントの開発中に使用され、プラットフォームはランダムな文字列を自動的に割り当てます。この文字列は、${id} である限り、コンポーネント インスタンス内で同じになります。コンポーネントの親ノードの ID またはクラスとして使用されると、セレクターの競合が解決されます。これは、コンポーネントの CSS
名前空間としても使用できるため、CSS の名前の競合を目に見えずに解決できます。 以上がプロジェクトの中核となる機能です。
また、スタンドアロン版のデータ統計を実装するストレージメソッドとして localStorage が使用され、現在のブラウザのコンポーネントの使用記録と各用途の設定を収集できます。これは主にローカル ストレージの操作です。フロントエンド テンプレートとコンポーネント テンプレートに関しては、最初のロード後に localStorage を使用してキャッシュされます。これらのコンテンツのキャッシュ戦略は異なるため、永続的に保存する必要があります。プロジェクト テンプレートは手動で更新する必要があり、コンポーネント テンプレートは状況に応じて決定する必要があります。保存されているコンテンツが多すぎる場合、それらをすべて削除するのは現実的ではありません。他のアプリケーションのストレージを誤って破損する可能性があります。ここでのメソッドは localStorage 操作をカプセル化するもので、特別なプレフィックスを削除するときは、ローカルに保存されたキーを調べて、それがキーと一致するかどうかを判断するだけで済みます。対応する値の取得メソッドでは、接頭辞を逆にキーに追加してから値を取得する必要があります。
さらに、localStorage は文字列アクセスのみをサポートしており、オブジェクト型へのアクセスを容易にするために、この変換では、値が一致した場合に文字を盲目的に変換することはできません。オブジェクトは自動的にオブジェクトに転送されます。ユーザーが実際にオブジェクト文字列を保存し、それを取り出すときにそれをそのまま戻したい場合があるため、この問題を解決するには、保存方法に小さなハックを行う必要があります。値がオブジェクトであることを検出すると、文字列に変換され、その前に識別文字列が続きます。 value メソッドは、この識別を検出した後でのみ次の文字列をオブジェクトに復元しますが、このメソッドはニーズを満たすことができます。このプレフィックスは固定されているため、理論的には常に宝くじの当選者に遭遇する可能性があります。この問題に対する他のより良い解決策があるかどうかはわかりません。
これらがプロジェクトの主な機能ポイントです。
リファクタリング
一つの復興
最初のリファクタリングでは Vue のみを使用しました。リファクタリングのプロセス中に最初に気づいたのは、当初テンプレート エンジンを呼び出して実行したかったことは、JS でイベントをバインドすることで実現できたことです。テンプレートやその他のさまざまな構文で直接実行できます。
もちろん、最も重要なことは双方向バインディングに基づいて、インターフェイスとデータを自動的に関連付けることができ、プログラムがある程度の自律性を持っているように感じられます。正常に動作する場合、開発者はあらゆる段階で事前に計画を立てる必要があり、これは jQuery よりも自由度が低いように見えます。レンガの移動を例に挙げると、jQuery はレンガを簡単に持ち上げたり、派手な方法で移動したりできる非常に柔軟なクレーンのようなものです。Vue は、レンガを特定の場所から別の場所に移動したいと指示します。特定の場所で何が起こるかは対処方法によって異なりますが、ボタンを押すとレンガが自動的に移動します。
どちらの方法にもそれぞれ長所と短所があります。クレーンをうまく運転すれば、非常に柔軟に動作できますが、短所は、何度もボタンを押して運転しなければならないことです。同時に自動的に走行するようにプログラムすることもできますが、事前に現場検査を実施し、他のすべての車両のスケジュールを設定し、すべての状況を明確に説明しなければ、車両が横転したり衝突したりするという欠点があります。 jQuery から Vue に切り替えると、「行動する前に計画を立てなければならない」という束縛感を確実に感じることになります。車に乗る前にそれについて話すことはできません。
再構築期間の作業の大部分は、Vue インスタンスを確立し、js の隅々に散らばるデータをデータに収集し、データを少しずつ操作する処理をメソッドに集約し、データのフィルタリング処理を計算結果に集約することです。このプロセスでは、すべての実装の詳細を明確に確認し、各実装方法が合理的であるかどうかを検討できます。実際には、クレーンを 1 つずつリモコンのボタンに押し込む元のプロセスを要約することになります。すべての要約が完了すると、Vue が完成します。例 これは、自動的に実行できる最終プロジェクトになります。
再構築後も、Vue の各種機能に依存して論理部分のコード量は減りましたが、ルーティングがないため、リフレッシュ ページのステータスが失われる問題は依然として残ります。 Vuex が使用されていないため、データ汚染の落とし穴が発生した場合、それを解決するにはディープ コピーを使用するしかなく、コンポーネント ベースの開発モデルにより、コード構成がより断片化されます。
二度目の再建
2 回目の再構築の目標は、ルーティング、Vuex、コード構成、Dingo 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 つまたは 2 つの js ファイルから 10 個ほどの js になり、モジュール化には webpack の代わりに seajs が使用されます。これは個人的に好きではないためです。 Webpack はまだ様子見の姿勢があり、私はまだそれを使用する必要性を感じていません。重要なのは、Webpack に基づいて開発されたコードには多くのプライベートなものが混在し、コードが非ネイティブになるということです。それなしでは実行できないとは思いますが、複数ページのシナリオでは、ローカル キャッシュと組み合わせた場合、seajs のほうが webpack よりも優れています。もちろん、それらの違いは jQuery の違いと同じです。本質的には同じではありません。どちらが最適であるかが重要です。
追記
2 つのリファクタリングの実践と落とし穴を経て、Vue を柔軟かつ自由に使用するには、開発者のプロジェクト アーキテクチャ機能に対する最小限の要件が必要になります。基本事項 また、jQuery テクノロジ スタックには存在しないファシリティ ビルダーの計画機能に対する最小要件もあります。Vue を使用するプロセスは、開発者が独自のルール システムを確立するように導くことができます。これは良いことであり、一般的な傾向です。結局のところ、真の自由はルールの中にのみ存在します。
この記事の事例を読んだ後は、この方法を習得したと思います。さらに興味深い情報については、php 中国語 Web サイトの他の関連記事に注目してください。
推奨読書:
以上がVueファミリーのバケットプロジェクト実践の詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
