Vue代码整洁之去重方法整理
在开始本篇的主题之前，让我们把上次遗留下来的问题都清理一下：
将其他组件中axios请求的地方封装起来。
这里就不把代码放在开头了，相关代码都放在文末，有兴趣了解的童鞋可以先往下翻。
好了，我们现在把上篇剩下的任务给完成了，接下来我们来正式开始本篇内容吧。
去重是什么
字面上意思：去除重复，在项目中，不可避免的会出现重复代码。但是如果不好好去处理这些重复代码，那很有可能就会给你很多“惊喜”。
如何为“重复”下一个定义呢？
从最浅显的层次来看，相同即是重复。在我们上面的代码中，每一个组件中都有这么一行代码：
importRequestSenderfrom'@/requestSender';
这就是重复代码，在每一个需要发起请求的组件中你都会需要写上这么一行代码。那么让我们就这个列举一些可能出现的问题：
某一天修改了文件名
某一天移动了该文件
那么项目中需要修改的地方将会是多少呢？而在修改中会产生手误的概率又会是多少呢？以上还是在单人开发的时候，如果团队协作开发，这些情况的概率又会是什么样的呢。
如何去重
当然，对于上面这种引入型的代码，类似移动文件，修改文件名这种操作。IDE就能很好的帮你处理，比如WebStorm如果你使用重构相关的功能去重命名，那么它会找出所有“疑似”引用的代码片段，你可以选择所有相关的引用同时修改。
这是一种手段，很好的解决了上面这些问题。
那么让我们来看看另一个重复代码的问题：
classRequestSender{
staticGetBlogList(){
returnaxios.get('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/list');
}
staticPublish(data){
returnaxios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/publish',data);
}
staticLogin(data){
returnaxios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/login',data);
}
staticSignup(data){
returnaxios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/signup',data);
}
}
上面的代码，重点不在函数噢。仔细看看它们有哪些地方重复了。
光从代码上来看，其实有很多“重复”的地方，比如说return、static、axios.get、axios.post。
这些重复有一部分是语法，有一部分是调用。这些都是不可避免的，因此这些重复代码并不在我们需要重构的范围内。那么，究竟是哪段代码呢？
https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io
准确来说，它并不算是代码。而是“硬编码”，从整体代码上来看，这是目前所有后台接口的域名。
在开发过程中，一般来说至少是会有两个环境存在：开发环境、线上环境。而它们两的后台接口域名一般而言又不会重复，难道每次发布前都手动改一下域名么？
我们先来列举一下可能会出现的问题：
开发环境、线上环境域名不一致
团队协作中，开发者之间的开发域名不一致
当线上/开发环境中的域名需要修改时
可以看到，当遇到上述问题时，项目中所有硬编码了域名的地方都是需要修改的，那么为什么要修改呢？
除了解决上面列举的具体问题之外，最根本的目的是：
保持唯一性
如果有两段/多段代码它们表示的含义完全一致，并且从目的上来说也是一致的。那么就应该尽可能将其只保留一处定义。
那么对于这个域名我们怎么处理呢？首先将其提炼出来：
staticHost='https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io';
这样，引用的地方就可以这么写：
staticGetBlogList(){
returnaxios.get(`${Host}/list`);
}
这样，当发现修改的时候，是不是只需要修改Host这么一个地方就好了呢？、
但是这样还存在问题，如果要发布，或者是在git、svn上协作的时候呢？每个人、每个环境都需要修改这个变量，并且还要在提交代码时移除掉自己的修改以避免冲突。
可配置化
Host的例子是非常常见的，当我们需要发布、团队协作的时候，环境不同是非常常见的，有可能在自己电脑上Host是localhost:8080，换在另一个人电脑上就是localhost:9099了。那么线上环境有可能又是xxx.xxx.com、xx.xxx.com/api诸如此类。
这里若羽实践的解决方案是：
将与环境相关的硬编码提炼成可配置项放入配置文件
配置文件模板化
配置模板文件多样化
真正的配置文件是不会被提交上去，只有一个模板文件。由于配置文件并不会被提交，所以开发者之间的环境差异就可以忽略了，大家根据自己的环境修改配置文件即可。
那么对于线上环境、测试环境等等，建立对应的配置文件模板即可。当发布时，使用对应环境的发布配置文件模板作为配置文件即可。
那么我们来实践一下：
新建配置模板文件config.js.template:
constconfig={
HOST:'',
};
exportdefaultconfig;
接下来复制粘贴模板文件，并重命名为config.js:
constconfig={
HOST:'https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io',
};
exportdefaultconfig;
接下来修改一下requestSender.js:
importaxiosfrom'axios';
importconfigfrom'@/config.js';
classRequestSender{
staticGetBlogList(){
returnaxios.get(`${config.HOST}/list`);
}
staticPublish(data){
returnaxios.post(`${config.HOST}/publish`,data);
}
staticLogin(data){
returnaxios.post(`${config.HOST}/login`,data);
}
staticSignup(data){
returnaxios.post(`${config.HOST}/signup`,data);
}
}
exportdefaultRequestSender;
好了，现在不管是在任何一个环境下，都可以游刃有余的切换域名了。而且这里面还有一个很有意思的事情：
所有的改动对于表现层而言是透明的。
简单来说，我们在这里重构了这么多的代码，然而我们并不需要修改任何一个视图组件中的代码！！！
表面上还是原来的样子，可实际上已经“打扫”过了。这也是重构中需要注意的一点：
步子迈小一点，迈准一点写在后面
上篇中有人问到若羽说封装请求的意义何在，axios本身就是带着Promise的支持了。
这里对这个问题做一个回应，立场仅代表若羽本人，并不为任何人“做代表”：
封装并非为了Promise，而是为了将“发送请求”的这个动作封装起来。因为这属于数据获取的行为，而后面then里的逻辑实际上是和业务挂钩：为视图设置数据。这是两个不同的行为，就像后端一样：ORM它仅仅是负责从数据库中取数据而已，真正对这个数据进行逻辑操作的，并不是它。这也是接下来博文的主题：专一，一个函数应当只负责一件事情。
这一篇文章便表示了另一层意思：去重，在第一层封装的过程中我们发现了域名的硬编码问题（不封装也是一样），因此在这里如果不做封装的话，即使将域名提炼出来，涉及到修改的文件同样也会较多。不过这种修改是一次性的。
以上便是若羽对上一篇中示例的解释。
欢迎大家发表评论，共同探讨。
上篇重构代码
edit.vue
Login.vue:
Signup.vue:
requestSender.js:
importaxiosfrom'axios';
classRequestSender{
staticGetBlogList(){
returnaxios.get('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/list');
}
staticPublish(data){
returnaxios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/publish',data);
}
staticLogin(data){
returnaxios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/login',data);
}
staticSignup(data){
returnaxios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/signup',data);
}
}
exportdefaultRequestSender;
以上就是关于Vue代码整洁之去重的相关知识点，感谢大家的阅读和对毛票票的支持。