有了方向才能付诸努力。如果没有方向，即使付出再多也很难见到结果。前端学习也是如此，如果只是简单的去堆业务的话，成长其实是比较慢的。我个人浅显的把我了解过的前端领域分为性能优化，工程化，BFF，监控四个方向。在这四个方向里面我个人是对性能优化比较感兴趣的。在最近开发需求的过程中也对EP项目有了一些了解，也发现了一些可以优化的点，然后也对EP进行了一些小优化。
用结果说话
先上两张图
=========分割线==========================================
很明显在对EP项目进行优化之后EP项目的评分提高了
名词介绍
- lighthouse：lighthouse是Chrome的一个网站性能测评工具，使用lighthouse可以对我们的页面进行评测并且给出建议。
- LCP：LCP关注的是首屏中最大元素渲染渲染的时间，和 FCP 不同的是，FCP 更关注浏览器什么时候开始绘制内容，比如一个 loading 页面或者骨架屏，并没有实际价值，所以 LCP 相较于 FCP 更适合作为首屏指标。
分析LCP
未使用的JavaScript会减慢页面加载速度：
- 如果JavaScript是阻塞渲染，则浏览器必须先下载、解析、编译和评估脚本，然后才能继续执行渲染页面所需的所有其他工作。
- 即使 JavaScript 是异步的（即不阻塞渲染），代码在下载时也会与其他资源竞争带宽，这会对性能产生重大影响。通过网络发送未使用的代码对于没有无限数据计划的移动用户来说也是一种浪费。
所以减少无用的资源的加载或者是把暂时用不到的资源推迟加载，也就是我们说的懒加载是可以很大程度上提升页面性能的。
先用lighthouse看一下EP首页影响LCP的因素可以看出opLogOptions和echarts是两个比较大的资源文件，所以就从这两个文件下手
优化
- 先看下echarts，这个是一个画图表的库，再看EP项目的首页，似乎没有图表的相关样式，再去代码里看下。好像只有质检监控的页面用到了这个库。
那既然只有这个页面用到了，其他页面其实就无需加载这个库，何况还是这么大的库，在返回来看代码，项目里把echarts挂在了Vue的原型上。
这样应该是为了写代码的时候方便使用，但是只是为了避免在其他页面再写一次import就让每个页面都要加载这个库就是有点得不偿失了，毕竟用户的体验还是比写代码舒服更重要的。
既然找到了问题的原因就可以解决了，其实解决起来也比较简单，在main.js里删除掉对echarts的引用，只在用到的页面引用即可。
现在再看项目加载的元素
可以看到首页没有加载echarts这个库了，这样就可以提高没有用到echarts库的页面的加载速度了。
- 然后再看下opLogOptions.d7a2dab1.js这个文件，这个很明显是我们打包出来的一个bundle，那就去项目里看一下。直接看router文件，很多路由用了懒加载，但是有个问题，懒加载的名字好像有点问题。
opLogOptions这个chunkName出现了4次，而且还和homePage命名相同，也就是首页和其他的3个页面打包到了一起。
顺便简单介绍一下懒加载，懒加载或者按需加载，是一种很好的优化网页或应用的方式。这种方式实际上是先把你的代码在一些逻辑断点处分离开，然后在一些代码块中完成某些操作后，立即引用或即将引用另外一些新的代码块。这样加快了应用的初始加载速度，减轻了它的总体体积，因为某些代码块可能永远不会被加载。上面这种问题相当于我每次进入首页都要加载其他的这几个页面，而其他页面可能我根本就不会打开。后来猜测应该是之前的同学写代码的时候直接粘贴的时候，没有注意这个懒加载的写法，所以才导致了这种问题。解决方法也很简单，就是把chunkName整理一下。
其实homePage基本都是一定要开的页面，也没啥好懒加载的。
总结一下
其实上面两个优化点涉及到的知识点并不高级，都是比较基础的知识点。但是还是有一些我们在开发中需要注意的点
- 前端的网络资源是很宝贵的，能少加载就少加载，用不到的尽量不要加载。如果不是使用率很高的库最好不要因为写起来方便使用
Vue.prototype.$echarts = echarts这种直接挂在原型上的写法，会导致加载无用资源的情况。有些时候我们可能只会用到某个插件或者库中的一个简单小功能，这个时候我们完全可以自己扒一下源码自己把需要的方法单独抽出来而没有必要引入整个库。 - 新的技术最好多研究研究再使用，比如懒加载可以优化项目，但是如果使用方式错误的话，带来的效果就会微乎其微。
组件方面的问题
在开发的时候遇到这样一个问题，在质检白名单的新需求里需要这样一个弹窗
产品同学说之前这个弹窗做过，可以复用，就去项目里找这个组件的代码，然后发现这个组件设计的有点小缺陷。
可以看到这个组件里的一些使用组件的人需要自定义的一些字段在组件里写死了，比如placehoulder，errormassage等，但是很明显在不同的业务场景下使用这个弹窗的时候需要的这种字段的值也不完全相同。如果直接在组件里写死的话组件的复用性就差了很多。但是为了复用我在重新copy一份这个组件然后只改里面的这些字段就显得有点笨重了。所以我们可以把placeholder，errormassge这种字段作为props。
这样下次使用组件的人就可以写自己的placeholder了。（tip：一般写组件的时候不会写
:placeholder="placeholder || '多个宝贝ID请用英文逗号隔开'"这样的代码，这是为了兼容之前用这个组件的地方，正常情况我们一般会写:placeholder="placeholder",placeholder的默认值一般也是“请输入”这种比较通用的文案）
再总结一下
我个人认为组件大致分为基础组件和业务组件，基础组件比如按钮、input这种其实现在各种组件库已经都提供了而且接受了市场的考验，已经能满足我们的99.9%的需求。所以我们不太需要自己去封装基础组件，最多可能就是改改样式。但是业务组件多变的，第三方组件库也有一些自己的业务组件但是可能不能满足我们的需求，所以我们需要封装各种各样的特殊业务场景的组件。而业务组件是由基础组件搭起来的，比如一个弹窗是由一些输入框和一个提交按钮构成的，那我们封装好的业务组件的props最好也包含业务组件里的基础组价原本就支持的props，比如按钮的onclick，input的placeholder等，命名也最好多参考下市面上常见的组件库里props的命名，这样别人在使用我们组件的时候也不用再去猜我们每个props是干什么的了。（tip：如果能给自己封装的业务组件写一个组件文档就再好不过了。）
