Before starting the topic of this article, let's clear up all the problems left over from the last time:
Put other components inaxiosEncapsulate the requested place.
I won’t put the code at the beginning here, but the relevant code is placed at the end of the article. If you are interested in learning about it, you can turn it down first.
Okay, we have completed the remaining tasks in the previous article now, so let’s officially start this article.
What is weight removal
Literally: remove duplicates, and in the project, duplicate code will inevitably appear. But if you don't handle these duplicate codes well, it is very likely that you will give you a lot of "surprise".
How to define "repeat" next?
From the simplest level, the same is the repetition. In our above code, each component has a line of code:
import RequestSender from '@/requestSender';
This is repeated code. In every component that needs to initiate a request, you will need to write such a line of code. So let's list some possible problems for this:
One day the file name was modified
Moved the file one day
So how many places will be modified in the project? And what is the probability of hand errors occur during modification? The above is still in single-person development. If the team develops in a collaborative manner, what will the probability of these situations be like?
How to re-heavy
Of course, for the above imported code, it is similar to moving files and modifying file names. IDE can help you handle it very well, for exampleWebStormIf you use refactoring related functions to rename it, it will find all the code snippets of "suspected" references, and you can select all related references to be modified at the same time.
This is a means that solves the above problems very well.
So let's take a look at another duplicate code problem:
class RequestSender {
static GetBlogList() {
return ('/list');
}
static Publish(data) {
return ('/publish', data);
}
static Login(data) {
return ('/login', data);
}
static Signup(data) {
return ('/signup', data);
}
}
The above code is not the function. Take a closer look at what they are repeated.
Just from the code, there are actually many "repeats", such asreturn、static、、。
Some of these repetitions are syntax and some are calls. These are inevitable, so these duplicate codes are not within the scope of what we need to refactor. So, which piece of code is it?
To be precise, it is not code. Instead, it is "hard coded". From the overall code point of view, this is the current background interface.domain name。
During the development process, generally speaking, at least two environments exist: the development environment and the online environment. The background interface domain names of the two of them generally do not repeat. Do you change the domain name manually before each release?
Let's first list the possible problems:
The domain names of the development environment and online environment are inconsistent
In team collaboration, development domain names are inconsistent among developers
When the domain name in the online/development environment needs to be modified
You can see that when encountering the above problem, all the projects are hard-codeddomain nameAll the places need to be modified, so why modify them?
In addition to solving the specific problems listed above, the most fundamental purpose is:
Stay unique
If there are two/multi-segment codes, their meanings are exactly the same, and they are also consistent in purpose. Then it should be kept only one definition as much as possible.
So how do we deal with this domain name? First extract it:
static Host = '';
In this way, the quoted place can be written like this:
static GetBlogList() {
return (`${Host}/list`);
}
In this way, when you find a modification, do you only need to modify it?HostWhat if such a place is good? ,
But there are still problems if you want to publish it orgit 、 svnWhat about when collaborating? Everyone and every environment need to modify this variable, and they also need to remove their own modifications when submitting the code to avoid conflicts.
Configurable
HostExamples of this are very common. When we need to publish and collaborate in teams, it is very common to have different environments, and it may be on our own computer.Hostyeslocalhost:8080, if you change it to another computerlocalhost:9099Now. Then the online environment may be 、/apiAnd so on.
Here, the solution to Ruoyu's practice is:
Refining environment-related hardcoded items into configurable items and putting them into configuration files
Configuration file template
Diversified configuration template files
The real configuration file will not be submitted, there is only one template file. Since the configuration file will not be submitted, the environment differences between developers can be ignored. You can modify the configuration file according to your own environment.
Then, for online environments, test environments, etc., you can create the corresponding configuration file template. When publishing, use the publish configuration file template of the corresponding environment as the configuration file.
Then let's practice:
Create a new configuration template file:
const config = {
HOST: '',
};
export default config;
Next, copy and paste the template file and rename it:
const config = {
HOST: '',
};
export default config;
Next, modify it:
import axios from 'axios';
import config from '@/';
class RequestSender {
static GetBlogList() {
return (`${}/list`);
}
static Publish(data) {
return (`${}/publish`, data);
}
static Login(data) {
return (`${}/login`, data);
}
static Signup(data) {
return (`${}/signup`, data);
}
}
export default RequestSender;
Well, now, no matter in any environment, you can easily switch domain names. And there is another interesting thing here:
All changes are transparent to the presentation layer.
Simply put, we have refactored so much code here, but we don't need to modify the code in any view component! ! !
It is still the same on the surface, but in fact it has been "cleaned". This is also a point that needs to be paid attention to in the reconstruction:
Take a smaller step, take a more accurate step. Write it in the back
In the previous article, someone asked Ruoyu what the meaning of the encapsulation request is.axiosIt's carrying itPromiseSupported.
Here is a response to this question. The position only represents Ruoyu himself and does not "represent" anyone:
Packaging is not forPromise, but to encapsulate the action of "send request". Because this is the behavior of data acquisition, and thenthenThe logic in it is actually linked to the business: setting data for the view. Here are two different behaviors, just like the backend:ORMIt is only responsible for fetching data from the database, and it is not what really logically operates on this data. This is also the topic of the next blog post: dedicated, a function should only be responsible for one thing.
This article expresses another meaning: deduplication, we discovered during the first layer of packaging.domain nameThe hard-code problem (the same is true if it is not encapsulated), so if you do not encapsulate it here, even if the domain name is extracted, there will be more files involved in modification. However, this modification is a one-time one.
The above is Ruoyu's explanation of the example in the previous article.
Everyone is welcome to comment and discuss together.
Refactoring the code in the previous article
<script>
import RequestSender from '@/requestSender'
export default {
name: "Edit",
data() {
return {
model: {
title: '',
content: '',
}
}
},
methods: {
submit() {
()
.then(res => {
if( === 200) {
this.$('Release Successfully');
}
})
}
}
}
</script>
:
<script>
import RequestSender from '@/requestSender';
export default {
name: "Login",
data() {
return {
model: {
username: '',
password: '',
}
}
},
methods: {
submit() {
()
.then(res => {
if( === 200) {
this.$('Login successfully');
}
})
}
}
}
</script>
:
<script>
import RequestSender from '@/requestSender';
export default {
name: "Signup",
data() {
return {
model: {
username: '',
password: '',
rePassword: ''
}
};
},
methods: {
submit() {
if( !== ){
this.$('The passwords for the two entry and exit are inconsistent.');
return ;
}
()
.then(res => {
if( === 200){
this.$("Registered successfully");
this.$('./login');
}
});
}
}
}
</script>
:
import axios from 'axios';
class RequestSender {
static GetBlogList() {
return ('/list');
}
static Publish(data) {
return ('/publish', data);
}
static Login(data) {
return ('/login', data);
}
static Signup(data) {
return ('/signup', data);
}
}
export default RequestSender;
The above are the relevant knowledge points about the neat and heavy removal of Vue code. Thank you for your reading and support.