1. Frame positioning
Framework is usually just an implementation of a design pattern, and it doesn't mean you can avoid all hierarchical design work in development.
The SPA framework is almost all built on the MVC or MVVM design patterns. These patterns are just macro-hierarchical designs. When the amount of code begins to increase as the project increases, there will be more and more problems. Many internal projects are still in use, and you will find that many controllers are outrageously large. Teams with a little experience will make good use of the controllers, service, filters, and routing and message mechanisms built by angularjs1 to complete basic splitting and decoupling. This can already allow their development capabilities to have medium-sized projects. Of course, only by mastering the essence of angularjs1 gameplay - directive teams can keep the code clear enough when dealing with large projects. Of course, this is just a work in code form and module division, which is equivalent to the bones of the code. If the business logic itself is clearer, more advanced modeling and design knowledge is needed to layer the business logic, such as the domain-driven model. If you are still using the version of development, you can refer to [How to refactor Controller】Carry out basic layered split design.
Interestingly, some teams believe that it is the original sin of not being able to carry large projects, and it has nothing to do with their development level, so they pin their hopes on the modern SPA framework supported by automation tools. However, if you have the opportunity to observe, you will find that many projects use new frameworks without essential differences from before. They just change the code that was so bloated before and stuffed it into the front-end project. Then, with the ES6 syntax and the simplicity of the new framework itself, they began to complacently think that this was the credit for their own reconstruction.
Remember, if you don't design the structure, even if you use the latest version of the most popular framework, the code you wrote will still be messy.
2. script split optimization in Vue development
Taking the Vue framework as an example, with the support of engineering tools and vue-loader, the mainstream development model is based on the single-file component form of *.vue. A typical vue component contains the following parts:
<template>
<!--View template-->
</template>
<script>
/*Writing component script*/
export default {
name:'component1'
}
</script>
<style>
/*Writing component style*/
</style>
The script part usually contains interactive logic, business logic, data conversion and DOM operations. If it is not organized, it can easily become chaotic. The essence of the *.vue file is View-layer code. It should be as light as possible and contains information related to the view, namely, feature declarations and event distribution. Other codes should theoretically be stripped away. In this way, when the project size increases, it is easier to focus on key information when it is maintained. The following provides some ideas on how to split script code. Some may be very basic principles. To put them together as complete as possible, you do not need to adopt all suggestions from the beginning.
1. Component division
This is the basis for weight reduction of the View layer. Splitting out the common view components, changing them to a message mechanism for communication, and even directly stripping out the business logic components containing the view and business code. All of them can effectively split the View layer and reduce the complexity of the code.
2. Split the business logic code
The biggest part of script is generally business logic. First, the business logic code is separated into independent [name]. modules. The intuitive advantage of this is to reduce the View layer. On the other hand, it removes the strong binding relationship between the business logic and the page. If other pages also involve individual methods in this business logic, they can be reused directly. Finally, when the project becomes more complicated and you decide to introduce vuex for state management, the View layer will be relatively easier to modify.
A component containing the basic logic of adding, deleting, modifying and searching is probably the following:
<script>
export default{
name:'XXX',
methods:{
handleClickCreate(){},
handleClickEdit(){},
handleClickRefresh(){},
handleClickDelete(){},
sendCreate(){},
sendEdit(){},
sendGetAll(){},
sendDelete(){}
}
}
</script>
A simple stripping method is to keep the interactive logic in the view layer, put part of the business logic code in another module, and then add it to the component instance method using the ES6 extension operator, as shown below:
<script>
import OrderBusiness from './';
export default{
name:'XXX',
methods:{
...OrderBusiness,
handleClickCreate(){},
handleClickEdit(){},
handleClickRefresh(){},
handleClickDelete(){},
}
}
</script>
This method is just a modular split in form and does not sort out the business logic itself. Another way is to build independent business logic services, and the code retained in the View layer is easily converted to the encoding style when using vuex:
<script>
import OrderBusiness from './';
export default{
name:'XXX',
methods:{
handleClickCreate(){
();
},
handleClickEdit(){
();
},
handleClickRefresh(){
();
},
handleClickDelete(){
();
}
}
}
</script>
The author’s suggestion is that the previous three examples can achieve gradual modifications as the project size grows.
3. Strip the data conversion code
In the development mode of separation of front-end and back-end, the data support required by the front-end needs to be obtained from the back-end request, but the original data requested is usually not directly used, and it may even cause a code error. For example, the time may be transmitted in the form of a timestamp, or when your code needs to use an object attribute, the back-end classmate hangs a default value NULL on the attribute, etc. On the other hand, interface changes during the development process are inevitable, so in the design of the code structure, the possible changes should be aggregated as much as possible.
A more practical approach is to establish a Transformer function for each interface. The data requested from the background is first transformed into a data structure that can be circulated and used by the foreground through the Transformer function, and add appropriate default values to the necessary properties to prevent errors. You can use function tools such as to process and reorganize the data you need here. Even if the data transmitted to you in the background does not need to be processed at the beginning, you can still retain a transmissive function or module description to remind other collaborative developers to adopt similar practices when facing this scenario. Its function is to provide directly available data for the logic layer. When the current-side code is getting heavier, the Transformer and Request parts can be easily moved to the middle layer.
4. Make good use of computed and filters to process data display
The conversion of the original data cannot cover all scenarios. This requires the use of computed and filters in customized display scenarios. They can be used to change the display results without changing the data, such as converting 0 or 1 in the data to unfinished and completed, or comparing the timestamp with the current time to more readable. Just now, 1 minute ago, 1 hour ago, 1 day ago, etc. These development scenarios cannot be processed by forced assignment. This can be handled using the computed attributes computed or filters filters. The difference is that computed is generally used inside components and is not universal, while filters are generally used in reusable scenarios. A global filter with the display effect capitalized in the following form:
('capitalize', function (value) {
if (!value) return ''；
value = ()；
return (0).toUpperCase() + (1)；
})
When using vuex for state management in a project, computed is usually replaced with getter in state.
5. Use directive to handle DOM operations
Although Vue provides the refs interface to directly operate the DOM at the logic level, we should avoid placing complex DOM operations here as much as possible. Sometimes there are many DOM changes on the page, and it is obviously unreasonable to use data-driven methods for each change. At this time, directive feature directive is needed, which is often used to supplement and implement some business logic-independent DOM changes (most of the business logic-related changes are automatically associated through data binding). The basic usage of directive can be directly referenced [Official Guide】 , it should be noted that many junior developers do not care much about memory leakage. They need to pay special attention to this in the use of directive. Usually, we will bind events in the bind event hook and use attributes to hold this listening function, and unbind the same listening function in the unbind hook. Even if you do not use custom instructions, you need to establish the encoding habit of unbinding the listener if necessary:
('clickoutside',{
bind:function (el, binding){
//Define the listener function handler(e) {
if (()) {
return false;
}
if (){
(e);
}
}
el.__clickOutSide__ = handler;
('click', handler);
},
unbind:function (el) {
('click',el.__clickOutSide__);
delete el.__clickOutSide__ ;
}
});
A simple directive example is provided in the demo that you can use to practice.
Summarize
The above are 5 suggestions for splitting view layer codes in Vue introduced to you by the editor. I hope they will be helpful to you. If you have any questions, please leave me a message and the editor will reply to you in time. Thank you very much for your support for my website!
If you think this article is helpful to you, please reprint it. Please indicate the source, thank you!