Vue 프로젝트를 최적화할 때 주의해야 할 사항은 무엇인가요?-JS 튜토리얼-php.cn

이 글은 주로 Vue 프로젝트를 최적화하는 방법을 소개합니다. 편집자는 이것이 꽤 좋다고 생각합니다. 이제 여러분과 공유하고 참고할 것입니다. 에디터 따라가서 살펴볼까요

오랜만에 블로그 포스팅을 작성하게 되었습니다. 이 글은 제가 반년 동안 vue 프레임워크를 사용해 본 경험을 아무렇지도 않게 이야기해 놓은 것입니다. vue-cli로 초기화된 프로젝트 또는 webpack 패키징을 사용하는 프로젝트에 적용 가능합니다.

몇일 전 Vue 프로젝트가 커질수록 최적화가 어려워지고 이는 불가피한 문제라고 말하는 것을 봤습니다. 성능에는 문제가 없습니다. 모든 주요 테스트 웹사이트에는 관련 데이터가 있습니다. 본론으로 들어가죠

기본 최적화

소위 기본 최적화는 모든 웹 프로젝트에 필요하며 문제의 근원입니다. HTML, CSS, JS는 각각 .vue 파일의 , <template>, <style>, <script>, 에 해당합니다. vue 프로젝트에서 최적화할 가치가 있는 점은 무엇입니까

，<template>,<style>,<script>，下面逐个谈下 vue 项目里都有哪些值得优化的点

template

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

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

v-show，v-if 用哪个？在我来看要分两个维度去思考问题，第一个维度是权限问题，只要涉及到权限相关的展示无疑要用 v-if，第二个维度在没有权限限制下根据用户点击的频次选择，频繁切换的使用 v-show，不频繁切换的使用 v-if，这里要说的优化点在于减少页面中 dom 总数，我比较倾向于使用 v-if，因为减少了 dom 数量，加快首屏渲染，至于性能方面我感觉肉眼看不出来切换的渲染过程，也不会影响用户的体验。
不要在模板里面写过多的表达式与判断 v-if="isShow && isAdmin && (a || b)"，这种表达式虽说可以识别，但是不是长久之计，当看着不舒服时，适当的写到 methods 和 computed 里面封装成一个方法，这样的好处是方便我们在多处判断相同的表达式，其他权限相同的元素再判断展示的时候调用同一个方法即可。
循环调用子组件时添加 key，key 可以唯一标识一个循环个体，可以使用例如 item.id 作为 key，假如数组数据是这样的 ['a' , 'b', 'c', 'a'],使用 :key="item" 显然没有意义，更好的办法就是在循环的时候 (item, index) in arr，然后 :key="index"来确保 key 的唯一性。

style

将样式文件放在 vue 文件内还是外？讨论起来没有意义，重点是按模块划分，我的习惯是放在 vue 文件内部，方便写代码是在同一个文件里跳转上下对照，无论内外建议加上 <style scopeed> 将样式文件锁住，目的很简单，再好用的标准也避免不了多人开发的麻烦，约定命名规则也可能会冲突，锁定区域后尽量采用简短的命名规则，不需要 .header-title__text 之类的 class，直接 .title 搞定。
为了和上一条作区分，说下全局的样式文件，全局的样式文件，尽量抽象化，既然不在每一个组件里重复写，就尽量通用，这部分抽象做的越好说明你的样式文件体积越小，复用率越高。建议将复写组件库如 Element 样式的代码也放到全局中去。
不使用 float 布局，之前看到很多人封装了 .fl -- float: left 到全局文件里去，然后又要 .clear，现在的浏览器还不至于弱到非要用 float 去兼容，完全可以 flex，grid 兼容性一般，功能其实 flex 布局都可以实现，float 会带来布局上的麻烦，用过的都知道不相信解释坑了。

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

script

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

多人开发时尽量保持每个组件 export default {} 内的方法顺序一致，方便查找对应的方法。我个人习惯 data、props、钩子、watch、computed、components。
data 里要说的就是初始化数据的结构尽量详细，命名清晰，简单易懂，避免无用的变量，isEditing 实际可以代表两个状态，true 或 false，不要再去定义 notEditing 来控制展示，完全可以在模板里 {{ isEditing ? 编辑中 : 保存 }}template
🎜🎜의미 태그, 임의 중첩 방지, 합리적인 이름 지정 속성 및 기타 표준 권장 사항은 논의되지 않습니다. 🎜🎜템플릿 부분은 구조화된 데이터를 표시하는 데 도움이 됩니다. Vue는 데이터를 통해 뷰를 구동합니다. 🎜
1. 🎜v-show에는 어떤 것을 사용해야 합니까? 아니면 v-if? 내 생각에는 이 문제를 두 가지 차원에서 생각해 볼 필요가 있는데, 첫 번째 차원은 권한 관련 표시가 포함되는 한 의심할 바 없이 두 번째 차원이 빈도를 기준으로 선택됩니다. , 자주 전환하려면 v-show를 사용하고, 드물게 전환하려면 v-if를 사용하세요. 여기서 언급할 최적화 포인트는 페이지의 전체 DOM 수를 줄이는 것입니다. 만약 DOM의 수를 줄이고 첫 번째 화면 렌더링 속도를 높이기 때문에, 성능에 관해서는 전환 렌더링 프로세스가 육안으로 볼 수 없으며 사용자 경험에 영향을 미치지 않을 것이라고 생각합니다. 🎜
2. 🎜템플릿 v-if="isShow && isAdmin && (a || b)"에 너무 많은 표현과 판단을 쓰지 마세요, 이런 표현은 그래도 식별할 수는 있지만 장기적인 해결책은 아닙니다. 불편해 보일 때 메서드에 적절하게 작성하고 계산하여 메서드에 캡슐화하면 동일한 표현식을 판단하기가 편리하다는 장점이 있습니다. 여러 위치에서 동일한 권한을 가진 다른 요소를 다시 사용할 수 있습니다. 디스플레이를 판단할 때 동일한 메소드를 호출하면 됩니다. 🎜
3. 🎜루프에서 하위 구성요소를 호출할 때 키를 추가하세요. 예를 들어 배열 데이터가 다음과 같은 경우 item.id를 키로 사용할 수 있습니다. 'a', 'b', 'c', 'a'], :key="item" 를 사용하는 것은 분명히 의미가 없습니다. , index) arr에서 반복할 때 key="index"를 사용하여 키의 고유성을 보장합니다. 🎜
🎜🎜style🎜🎜
1. 🎜스타일 파일을 vue 파일 내부에 넣을까요, 아니면 외부에 넣을까요? 토론의 의미가 없습니다. 초점은 모듈별로 나누는 것입니다. 내부 또는 외부 제안에 관계없이 동일한 파일에서 위아래로 코드를 작성하는 것이 편리합니다. code> code>는 스타일 파일을 잠급니다. 목적은 매우 간단합니다. 표준이 아무리 사용하기 쉽다고 해도 합의된 명명 규칙은 문제를 피할 수 없습니다. 또한 충돌이 발생합니다. 영역을 잠근 후 짧은 명명 규칙을 사용하고 가 필요하지 않은 경우 header-title__text 를 사용하세요. 🎜
2. 🎜이전 글과 구별하기 위해 글로벌 스타일 파일에 대해 이야기해보자. 글로벌 스타일 파일은 모든 컴포넌트에서 반복되지 않기 때문에 최대한 추상적이어야 한다. 가능한 한 보편적으로 수행됩니다. 추상화의 이 부분이 완료되면 스타일 파일의 크기가 작아지고 재사용률이 높아집니다. Element 스타일 등 복사한 컴포넌트 라이브러리의 코드를 글로벌에 넣는 것을 권장합니다. 🎜
3. 🎜float 레이아웃을 사용하지 마세요. 많은 사람들이 .fl -- float: left 를 전역 파일에 캡슐화한 다음 .clear를 요청하는 것을 보았습니다. 프로세서는 호환성을 위해 float를 사용해야 할 정도로 약하지 않습니다. flex와 완벽하게 호환되며 그리드 호환성은 평균입니다. 실제로 이 기능은 flex 레이아웃에서 구현될 수 있습니다. 내가 그 설명을 믿지 않는다는 것을 알고 있습니다. 🎜
🎜기타 일반적인 사양에 대해서는 여기서 자세히 다루지 않겠습니다. 🎜🎜🎜script🎜🎜🎜이 부분이 최적화하기 가장 어려운 부분이기도 한데 개인적인 의견을 말씀드리겠습니다. 🎜
1. 🎜여러 사람이 개발하는 경우 각 구성 요소 내보내기 기본값 {} 의 메서드 순서를 일관되게 유지하여 쉽게 사용할 수 있도록 하세요. 해당 방법을 찾는 것입니다. 저는 개인적으로 데이터, 소품, 후크, 시계, 계산 및 구성 요소를 사용합니다. 🎜
2. 데이터에서 제가 말하고 싶은 것은 초기화된 데이터의 구조가 최대한 상세해야 하고, 이름이 명확해야 하고, 간단하고 이해하기 쉬워야 하며, 쓸모 없는 변수는 피해야 한다는 것입니다. isEditing은 실제로 두 가지를 나타낼 수 있습니다. 상태, 참 또는 거짓, 다시 정의하지 마십시오. 디스플레이를 제어하기 위해 notEditing, 템플릿 {{ isEditing ? Editing: Save}}🎜에서 완전히 사용할 수 있습니다.
3. props 상위 및 하위 구성 요소에 값을 전달할 때 다음을 시도하십시오:width="" :heigth="" Do not:option={} 개선의 장점은 필요한 매개변수만 있다는 것입니다. 수정된 항목은 하위 구성 요소 소품에 전달되어야 하는지 여부와 문제 해결을 용이하게 하고 값 전송을 더욱 엄격하게 만들기 위한 기본값을 추가합니다.
4. 훅은 라이프 사이클의 의미, 언제 요청해야 하는지, 언제 메소드를 로그아웃해야 하는지, 어떤 메소드를 로그아웃해야 하는지 이해하면 됩니다. 간단하고 이해하기 쉽게 공식 홈페이지에 적혀있습니다.
5. 메서드의 각 메서드는 단순해야 하며 한 가지 작업만 수행해야 합니다. 너무 많은 매개변수 없이 짧고 재사용 가능한 메서드를 캡슐화하세요. 개발을 위해 lodash에 크게 의존하는 경우 방법은 훨씬 간단해 보이지만 전체 번들 크기가 더 커지게 됩니다. 프로젝트에서 소수의 방법만 사용하는 경우 loadsh를 로컬로 도입할 수 있습니다. lodash를 사용하려면 util.js 파일을 직접 캡슐화할 수 있습니다
6. 어떤 것을 사용할지에 대한 질문은 공식 웹사이트의 예를 참조하세요. 계산된 속성은 주로 필터 변환 레이어입니다. . 일부 호출 방법을 추가하지 마십시오. watch의 기능은 데이터 변경을 모니터링하여 this.$store.dispatch('update', { ... })
구성 요소 최적화

와 같은 이벤트를 트리거하는 것입니다. 합리적으로 해체하는 것은 프로젝트 규모에 따라 다릅니다. 소규모 프로젝트는 vuex, axios 등을 사용하지 않고도 몇 가지 구성 요소만으로 완료할 수 있습니다. 레이아웃 캡슐화, 버튼, 폼, 프롬프트 상자, 캐러셀 등. 이러한 세부 사항을 작성할 시간이 없다면 Element 라이브러리를 직접 사용하는 것이 좋습니다. tooptimize
1. 컴포넌트는 명확한 의미를 가지며 유사한 업종만 취급합니다. 재사용성이 높을수록 좋고, 구성 가능성이 강할수록 좋습니다.
2. 구성 요소를 직접 캡슐화하거나 소품 구체화 구성 규칙을 따를지 여부.
3. 컴포넌트 분류, 나는 습관적으로 페이지, 페이지 항목, 레이아웃의 세 가지 범주로 나눕니다. 페이지 항목은 배너, 측면 등 페이지의 각 레이아웃 블록에 속합니다. , 아이콘, 스크롤탑 등 여러 페이지에 두 번 이상 나타나는 구성 요소입니다.
vue-router 및 vuex 최적화

vue-router 경로 전환 외에도 가장 일반적으로 사용되는 로직은 권한 처리 및 권한 제어입니다. 여기서는 자세히 설명하지 않겠습니다. 관련된 데모와 기사가 많기 때문에 최적화에 관해서는 구성 요소 지연 로딩을 언급할 가치가 있습니다

정오의 공식 웹사이트 링크는 다음과 같습니다. 위의 예는 다음과 같습니다
```
const Foo = r => require.ensure([], () => r(require(&#39;./Foo.vue&#39;)), &#39;group-foo&#39;) 
const Bar = r => require.ensure([], () => r(require(&#39;./Bar.vue&#39;)), &#39;group-foo&#39;) 
const Baz = r => require.ensure([], () => r(require(&#39;./Baz.vue&#39;)), &#39;group-foo&#39;)
```
로그인 후 복사
이 코드는 Foo, Bar, Baz의 세 가지 구성 요소를 결합합니다. group-foo라는 청크 파일로 패키지됩니다. 물론 나머지 파일은 js 파일입니다. 웹사이트가 로드되면 어떤 청크를 로드해야 하는지 자동으로 분석해 주지만, 개별 패키지의 총 용량은 커지겠지만, 첫 화면을 요청하는 속도를 보면 훨씬 크다. 더 빠르게.
vuex에는 여러 가지 문제와 해결 방법이 있습니다
웹사이트가 충분히 크면 상태 트리의 루트 부분에 많은 필드가 있습니다. 이 문제를 해결하려면 vuex를 모듈화해야 합니다. 솔루션을 통해 vuex를 초기화할 때 모듈을 구성할 수 있습니다. 각 모듈에는 여러 상태 트리로 보이지만 실제로는 rootState를 기반으로 하는 하위 트리인 상태, 작업 등이 포함되어 있습니다. 세분화 후에는 전체 상태 구조가 명확해지고 관리가 훨씬 쉬워집니다.
vuex의 유연성으로 인해 전체 폐쇄 루프는 store.dispatch('action') -> commit -> getter -> API 문서에서는 mapState, mapGetters, mapActions 및 mapMutations 메소드를 제공하므로 일부 중간 링크는 생략할 수 있습니다. 그런 다음 구성 요소의 모든 단계를 직접 호출하거나 소규모 프로젝트에 대해 원하는 대로 호출할 수 있습니다. 또는 대규모 프로젝트를 사용할 때 vuex 사용의 통일성을 고려해야 합니다. 프로세스가 아무리 간단하더라도 전체 폐쇄 루프를 완료하여 통합 코드를 형성하고 나중에 관리를 용이하게 하는 것이 좋습니다. 내 구성 요소에 나타날 수 있으며 나머지 프로세스는 모두 store라는 vuex 폴더에서 수행됩니다.
위의 내용을 바탕으로 각 프로세스에서 수행해야 할 작업에 대해 이야기해 보겠습니다. 데이터 구조나 필드 이름 지정에서 프런트엔드와 백엔드 데이터에 불일치가 있어야 합니다. 그러면 어떤 단계에서 로직을 처리해야 할까요? 데이터 변환? 어떤 사람들은 어떤 단계든 달성할 수 있다고 말할 것입니다. 실제로는 그렇지 않습니다. 제 제안은 다음과 같습니다
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: { 
 &#39;vue&#39;: &#39;Vue&#39;, 
 &#39;vue-router&#39;: &#39;VueRouter&#39;, 
 &#39;vuex&#39;: &#39;Vuex&#39;, 
 &#39;axios&#39;: &#39;axios&#39; 
}
```
로그인 후 복사
此时的 vender 包会非常小，如果不够小还可以拆分其他的库，此时增加了请求的数量，但是远比加载一个 1.4M 的 bundle 快的多。

总结

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

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

相关文章：

在Webpack中如何加载SVG

webpack打包配置（详细教程）

在Javascript中自适应处理方法