Vue プロジェクトを最適化するときは何に注意する必要がありますか?

この記事では主に Vue プロジェクトを最適化する方法を紹介します。編集者がそれを参考にさせていただきます。編集者をフォローして見てみましょう

久しぶりにブログ記事を書きます この記事は私が半年ほどVueフレームワークを使ってみた経験をまとめたものです この記事はあくまで雑談です。 vue-cli によって初期化されたプロジェクト、または webpack パッケージ化に依存するプロジェクトに適用されます。

数日前、Vue プロジェクトが大きくなるほど最適化が難しくなり、多くの苦痛が生じると言っているのを見かけましたが、これは最終的には解決されるべき問題であり、パフォーマンスには問題ありません。すべての主要なテスト Web サイトには関連データがあります。本題に入りましょう

基本的な最適化

いわゆる基本的な最適化は、あらゆる Web プロジェクトに必要であり、問​​題の根本です。 HTML、CSS、および JS は、それぞれ .vue ファイルの 、<template>、<style>、<script>、</style></template> に対応します。 vue プロジェクトで最適化する価値のあるポイントは何ですか

，d477f9ce7bf77f53fbcf36bec1b69b7a,c9ccee2e6ea535a969eb3f532ad9fe89,3f1c4e4b6b16bbbd69b2ee476dc4f83a，下面逐个谈下 vue 项目里都有哪些值得优化的点

template

语义化标签，避免乱嵌套，合理命名属性等等标准推荐的东西就不谈了。

模板部分帮助我们展示结构化数据，vue 通过数据驱动视图，主要注意一下几点

1. v-show，v-if 用哪个？在我来看要分两个维度去思考问题，第一个维度是权限问题，只要涉及到权限相关的展示无疑要用 v-if，第二个维度在没有权限限制下根据用户点击的频次选择，频繁切换的使用 v-show，不频繁切换的使用 v-if，这里要说的优化点在于减少页面中 dom 总数，我比较倾向于使用 v-if，因为减少了 dom 数量，加快首屏渲染，至于性能方面我感觉肉眼看不出来切换的渲染过程，也不会影响用户的体验。

2. 不要在模板里面写过多的表达式与判断 v-if="isShow && isAdmin && (a || b)"，这种表达式虽说可以识别，但是不是长久之计，当看着不舒服时，适当的写到 methods 和 computed 里面封装成一个方法，这样的好处是方便我们在多处判断相同的表达式，其他权限相同的元素再判断展示的时候调用同一个方法即可。

3. 循环调用子组件时添加 key，key 可以唯一标识一个循环个体，可以使用例如 item.id 作为 key，假如数组数据是这样的 ['a' , 'b', 'c', 'a'],使用 :key="item" 显然没有意义，更好的办法就是在循环的时候 (item, index) in arr，然后 :key="index"来确保 key 的唯一性。

style

1. 将样式文件放在 vue 文件内还是外？讨论起来没有意义，重点是按模块划分，我的习惯是放在 vue 文件内部，方便写代码是在同一个文件里跳转上下对照，无论内外建议加上 192521596740c72ca3a5b3d83e125015 将样式文件锁住，目的很简单，再好用的标准也避免不了多人开发的麻烦，约定命名规则也可能会冲突，锁定区域后尽量采用简短的命名规则，不需要 .header-title__text 之类的 class，直接 .title 搞定。

2. 为了和上一条作区分，说下全局的样式文件，全局的样式文件，尽量抽象化，既然不在每一个组件里重复写，就尽量通用，这部分抽象做的越好说明你的样式文件体积越小，复用率越高。建议将复写组件库如 Element 样式的代码也放到全局中去。

3. 不使用 float 布局，之前看到很多人封装了 .fl -- float: left 到全局文件里去，然后又要 .clear，现在的浏览器还不至于弱到非要用 float 去兼容，完全可以 flex，grid 兼容性一般，功能其实 flex 布局都可以实现，float 会带来布局上的麻烦，用过的都知道不相信解释坑了。

至于其他通用的规范这里不赘述，相关文章很多。

script

这部分也是最难优化的点，说下个人意见吧。

1. 多人开发时尽量保持每个组件 export default {} 内的方法顺序一致，方便查找对应的方法。我个人习惯 data、props、钩子、watch、computed、components。

2. data 里要说的就是初始化数据的结构尽量详细，命名清晰，简单易懂，避免无用的变量，isEditing 实际可以代表两个状态，true 或 false，不要再去定义 notEditing 来控制展示，完全可以在模板里 {{ isEditing ? 编辑中 : 保存 }}テンプレート

   🎜🎜 セマンティックタグ、ランダムなネストの回避、属性の合理的な名前付け、およびその他の標準的な推奨事項については説明しません。 🎜🎜テンプレート部分は構造化データを表示するのに役立ちます。Vue は次の点に注意してください🎜
   1. 🎜 v-show にはどれを使用すればよいですか。それとも、もしも？私の考えでは、問題は 2 つの次元で考える必要があります。最初の次元はパーミッションに関する問題であり、v-if は間違いなく頻度に基づいて選択されます。ここで言及する最適化ポイントは、ページ内の DOM の総数を減らすことです。 DOM の数が減り、最初の画面のレンダリングが高速化されるため、パフォーマンスに関しては、レンダリングの切り替えプロセスが目に見えず、ユーザー エクスペリエンスに影響を与えることはないと思います。 🎜
   2. 🎜テンプレートにあまり多くの式や判断を書かないでください v-if="isShow && isAdmin && (a || b)", このような式ですが識別することはできますが、長期的な解決策ではありません。不快に思われる場合は、それをメソッドに記述し、計算してメソッドにカプセル化します。この利点は、同じ式を判断するのに便利であることです。複数の場所に同じ権限を持つ他の要素を再度使用することもできます。表示を判断するときに同じメソッドを呼び出すだけです。 🎜
   3. 🎜 ループ内でサブコンポーネントを呼び出すときにキーを追加します。たとえば、配列データが次のような場合、キーとして item.id を使用できます。 'a', 'b ', 'c', 'a'], :key="item" の使用は明らかに無意味です。より良い方法は、 (item) を使用することです。 、index) arr でループするときに、then:key="index" を使用してキーの一意性を確保します。 🎜
   🎜🎜style🎜🎜
   1. 🎜スタイル ファイルを vue ファイルの内側または外側に置きますか?議論するのは無意味です。私の習慣は、内部または外部の提案に関係なく、vue ファイル内でコードを記述するのに便利です。 code> bab64a26f295faccf2facf6b9a41e4d8 code> はスタイル ファイルをロックします。その目的は非常に単純です。標準がどれほど使いやすいものであっても、合意された名前付けルールによって問題が発生する可能性があります。領域をロックした後は、短い名前付けルールを使用するようにしてください。header-title__text などのクラスについては、単に .ti​​tle を使用してください。 🎜
   2. 🎜 前の記事と区別するために、グローバル スタイル ファイルについて説明します。グローバル スタイル ファイルは、すべてのコンポーネントで繰り返されるものではないため、できるだけ抽象的なものにする必要があります。抽象化のこの部分ができる限り普遍的に行われるようにすることで、スタイル ファイルのサイズが小さくなり、再利用率が高くなります。コピーしたElement styleなどのコンポーネントライブラリのコードをグローバルに入れることを推奨します。 🎜
   3. 🎜 float レイアウトを使用しないでください。 .fl -- float: left をグローバル ファイルにカプセル化してから、.clear を要求する人がたくさんいます。プロセッサは互換性のために float を使用する必要があるほど弱くはありません。flex と完全に互換性があり、実際、この機能は flex レイアウトで実装できます。私がその説明を信じていないことはわかっています。 🎜
   🎜その他の一般的な仕様については、ここでは詳しく説明しません。関連記事がたくさんあります。 🎜🎜🎜script🎜🎜🎜 この部分は最適化が最も難しい部分でもあります。私の個人的な意見を言わせてください。 🎜
   1. 🎜 複数人で開発する場合は、作業を容易にするために、各コンポーネント export default {} 内のメソッドの順序を一貫した状態に保つようにしてください。対応するメソッドを見つけます。私は個人的にデータ、プロップ、フック、ウォッチ、コンピューテッド、コンポーネントを使用しています。 🎜
   2. データで言いたいのは、初期化されたデータの構造はできるだけ詳細で、明確な名前が付けられ、シンプルで理解しやすいものである必要があり、isEditing は実際には 2 つの変数を表すことができるということです。 true または false の状態は、表示を制御するための notEdit を再度定義しないでください。テンプレート {{ isEditing Editing: Save}} で完全に使用できます。

   3. props 親コンポーネントと子コンポーネントに値を渡すときは、次のようにしてください:width="" :heigth="" しないでください:option={} 必要なパラメーターのみを指定できることです。子コンポーネントの props にデータ型を追加し、エラーのトラブルシューティングを容易にし、値の転送をより厳密にするためにデフォルト値を追加します。

   4. フックは、ライフサイクルの意味、いつリクエストされるべきか、いつメソッドをログアウトすべきか、どのメソッドをログアウトする必要があるかを理解する必要があるだけです。シンプルでわかりやすく、公式サイトに書かれています。

   5. メソッドの各メソッドはシンプルでなければならず、パラメータが多すぎない短くて再利用可能なメソッドをカプセル化するようにしてください。開発に lodash に大きく依存している場合、メソッドははるかに単純に見えますが、プロジェクトで少数のメソッドのみが使用されている場合は、loadsh をローカルに導入できます。 lodash を使用したい場合は、util.js ファイルを自分でカプセル化できます

   6. どちらを使用するかについては、計算された属性は主にフィルター変換のレイヤーを参照してください。いくつかの呼び出しメソッドを追加しないでください。watch の機能は、データの変更を監視したり、this.$store.dispatch('update', { ... })

   コンポーネントの最適化

   などのイベントをトリガーしたりすることです。プロジェクトの規模に応じて解体するのが合理的です。小規模なプロジェクトであれば vuex や axios などを使用せずに、いくつかのコンポーネントだけで完了できます。規模が大きくなると、コンポーネントを細分化する必要があります。より詳細な方が良いです。レイアウトのカプセル化、ボタン、フォーム、プロンプト ボックス、カルーセルなどを含みます。そのような詳細を記述する時間がない場合は、Element コンポーネント ライブラリのコードを参照することをお勧めします。クリックして最適化します
   1. コンポーネントには明確な意味があり、同様のビジネスのみを処理します。再利用性が高いほど優れており、構成可能性が強いほど優れています。

   2. コンポーネントを自分でカプセル化するか、props 改良を構成するルールに従うか。

   3. コンポーネントの分類は、ページ、ページアイテム、レイアウトの3つのカテゴリに分けられます。ページは、バナー、サイドなどのページ内の各レイアウトブロックに属するページです。アイコン、scrollTop など、複数のページに少なくとも 2 回表示されるコンポーネント。

   vue-router と vuex の最適化

   vue-router ルートの切り替えに加えて、最も一般的に使用されるロジックは、アクセス許可の処理とアクセス許可の制御です。ここでは詳細には触れませんが、関連するデモや記事がたくさんあるので、最適化に関して言えば、コンポーネントの遅延読み込みについて言及する価値があります
   正午の公式 Web サイトのリンクは、上記の例は次のとおりです

   const Foo = r => require.ensure([], () => r(require('./Foo.vue')), 'group-foo') 
   const Bar = r => require.ensure([], () => r(require('./Bar.vue')), 'group-foo') 
   const Baz = r => require.ensure([], () => r(require('./Baz.vue')), 'group-foo')

   
   このコードは、Foo、Bar、Baz の 3 つのコンポーネントを組み合わせたもので、ファイルの残りの部分は group-foo という名前のチャンク ファイルにパッケージ化されています。 Web サイトがロードされると、どのチャンクをロードする必要があるかを自動的に分析します。ただし、個別のパッケージの総量は大きくなりますが、最初の画面のリクエスト速度を見ると、それははるかに高速です。もっと早く。
   

   vuex にはいくつかの問題と解決策があります
   Web サイトが十分に大きい場合、状態ツリーのルート部分に多くのフィールドが存在するため、この問題を解決するには、vuex をモジュール化する必要があります。これにより、vuex の初期化時にモジュールを構成できるようになります。各モジュールには状態、アクションなどが含まれており、これらは複数の状態ツリーのように見えますが、実際には rootState に基づくサブツリーです。細分化後は、全体の状態構造が明確になり、管理がはるかに容易になります。
   vuex の柔軟性により、完全な閉ループは、store.dispatch('action') -> commit -> getter -> になります。 API ドキュメントには、mapState、mapGetters、mapActions、mapMutations のメソッドが用意されているため、中間リンクの一部は省略できます。これにより、コンポーネント内の任意のステップを直接呼び出すことも、小規模なプロジェクトの場合は任意に呼び出すこともできます。 vuex を使用する場合、私の提案は、プロセスがどれほど単純であっても、閉じたループ全体を実行して、後でのディスパッチとマップゲッターのみの管理を容易にすることです。コンポーネントに表示することが許可されており、残りのプロセスはすべてstoreという名前のvuexフォルダーで実行されます。
   上記の点に基づいて、各プロセスで何を行う必要があるかについて説明します。データ構造またはフィールド名のいずれかで、フロントエンドとバックエンドのデータに不一致がある必要があるため、どのステップでロジックを処理する必要があるかについて説明します。データ変換の?どのステップでも達成できると言う人もいますが、実際にはそうではありません。コンポーネント内で渡す必要があるパラメータのデータ構造とフィールド名をディスパッチ送信前に処理します。
   アクションによってできること このモジュールは非同期、状態、rootState、コミット、ディスパッチ、ゲッターをサポートしているため、多くのことができます。これは、責任が重いことを示しています。まず、バックエンドが他のデータを必要とする場合です。モジュールの場合、 rootState を通じて値を取得し、それを元のデータに統合する必要があります。次のステップでは、リクエストと提案 (async await + axios) を発行し、データを取得した後にフィルターして変換し、コミットを送信します。突然変異

3. 这一步是将转换后的数据更新到 state 里，可能会有数据分发的过程（传进一个 object 改变多个 state 中 key 的 value），可以转换数据结构，但是尽量不做字段转换，在上一步做

4. 此时的 store 已经更新，使用 getter 方法来取值，token: state => state.token，单单的取值，尽量不要做数据转换，需要转换的点在于多个地方用相同的字段，但是结构不同的情况（很少出现）。

5. 在组件里用 mapGetters 拿到对应的 getter 值。

打包优化

上面说了代码方面的规范和优化，下面说下重点的打包优化，前段时间打包的 vender bundle 足足 1.4M，app bundle 也有 270K，app bundle 可以通过组件懒加载解决，vender 包该怎么解决？

有人会质疑是不是没压缩或依赖包没去重，其实都做了就是看到的 1.4M。

解决方法很简单，打包 vender 时不打包 vue、vuex、vue-router、axios 等，换用国内的 bootcdn 直接引入到根目录的 index.html 中。

例如：

<script src="//cdn.bootcss.com/vue/2.2.5/vue.min.js"></script> 
<script src="//cdn.bootcss.com/vue-router/2.3.0/vue-router.min.js"></script> 
<script src="//cdn.bootcss.com/vuex/2.2.1/vuex.min.js"></script> 
<script src="//cdn.bootcss.com/axios/0.15.3/axios.min.js"></script>

在 webpack 里有个 externals，可以忽略不需要打包的库

externals: { 
 'vue': 'Vue', 
 'vue-router': 'VueRouter', 
 'vuex': 'Vuex', 
 'axios': 'axios' 
}

此时的 vender 包会非常小，如果不够小还可以拆分其他的库，此时增加了请求的数量，但是远比加载一个 1.4M 的 bundle 快的多。

总结

本文谈的优化可以解决部分性能问题，实际开发细节很多，总之按着规范写代码，团队的编码风格尽量统一，处理细节上多加思考，大部分性能问题都能迎刃而解。

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

在Webpack中如何加载SVG

webpack打包配置（详细教程）

在Javascript中自适应处理方法

以上がVue プロジェクトを最適化するときは何に注意する必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。