Shulou(Shulou.com)06/01 Report--

Most people do not understand the knowledge points of this "Vue Business case Analysis" article, so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can gain something after reading this article. Let's take a look at this "Vue Business case Analysis" article.

Writing business, for a front-end, should be a normal thing, business marked demand, front-end er according to the needs of the product and the designer's design draft to develop the corresponding web application, whether it is a simple page or a complex system, more or less mixed with business logic. However, do we sometimes write business logic for the purpose of writing business logic? as a coquettish nian who fights with business for many years, I think the business we write is not just to complete simple tasks within the schedule, but to hone our ability to write business, and learn to design a set of flexible, maintainable and understandable business code according to the actual situation.

What exactly does the "actual scene" mentioned above refer to? the answer is not unique. Often the problems encountered in practice can be a kind of scene, and we should learn to understand these scenarios. Of course, the scene not only boils down to the prd of the product, but also is often closely related to the data structure provided by the back end. The exaggerated analogy is that the product needs a dish with both color, flavor and flavor, and the front end is like a cook, but the kitchen utensils on hand and the ingredients of not enough varieties, but to cook a good dish is actually a craft. Cut the crap and go straight to the recipe:

Scene one

Step box: step 1-> step 2-> step 3

This is a common example, this is a set of processes, and all we have to do is collude with the whole process to the end. This kind of example is common to the form, in addition to executing sequentially, it can also provide the previous button for the user to return to the previous step and re-fill it out.

Use Vue to design:

The parent component can be a custom dialog component with pages for each process

This is a standard set of textbook writing, , actually I don't mind using Vue's built-in Component:

Import stepOne from'. / step-one'

Import stepTwo from'. / step-two'

Import stepThree from'. / step-three'

Const MAP = {

0: stepOne

1: stepTwo

2: stepThree

}

Export default {

Data () {

Return {

Active: 0 / / 0 represents the index of the first page

}

}

Computed: {

Conf () {

Return {

Component: MAP [this.active]

Props: {...}

Listeners: {...}

}

}

}

}

At first glance, there is nothing special about the page, but the problem often develops from two directions: horizontal expansion and vertical expansion.

Specifically, if the product has to add another step page at this time, but from the point of view of development, we can not only consider the step of the product, but may add N steps (to be more complicated). Of course, if the product plays like this, the interaction on this page is still very poor.

Of course, the multi-page approach is still more likely to use Vue's built-in component.

When it comes to playing with design, let's talk about interfaces. This form design is nothing more than two operations, add and edit. Ideally, when editing, the front end wants the data of each page to be obtained independently, not to mention the dependency between each page, but the reality is that the backend will cram all the data of these pages into an object and return from the interface. This simply increases the complexity of the front-end processing.

For this scenario, the general operations of the front end are:

This is the most conventional approach, but if each page needs to pass a different props, the parent component can become very bloated.

At this time, let's consider it from a vertical point of view:

Vertical problems increase the complexity of Event Emits and Pass Props operations, which will cause great trouble for our daily maintenance. At this point, some people may suggest that using Vuex,Vuex does make it easy for us to manage state, and this state can be obtained in every component, as long as it is obtained instantly through a simple mapState. But the use of Vuex should also be based on the actual scene, if only 2 pages, the use of Vuex sometimes increases the workload, this is very contradictory, we have to use the simplest way to deal with, but also to consider whether the expansion should use Vuex, at this time, I still suggest that you think carefully, or and the product on the page design trend to understand a general.

Horizontal and vertical problems are just a simple start, but now the scenario is a little more complex and there will be dependencies between pages.

Specifically, the data change of page one form will affect the data display of page 2, and the data change of page 2 will affect the data display of page 3.

In fact, we also have a better way to deal with it, we need a Controller.

Class Manage {

Constructor () {

This.step1 = null

This.step2 = null

This.step3 = null

}

Add (step, instance) {

This [step] = instance

}

}

Export default new Manage ()

Page level:

Import manage from'. / Manage.js'

Export default {

Name: 'Step1'

...

...

...

Created () {

Manage.add ('step1', this)

}

}

Import manage from'. / Manage.js'

Export default {

Name: 'Step2'

...

...

...

Created () {

Manage.add ('step2', this)

}

}

In this way, the data sharing between components can be processed through controller, the instance of each component can be obtained and the data can be obtained directly.

In addition, we can inject a store into the controller object.

Const store = new Vue ({

Data () {

Return {...}

}

})

Class Manage {

Constructor () {

This.store = store

}

}

This allows some data to be shared between components.

Before writing business, we have to tear down more with the product to understand what the product wants to do, rigid requirements, and then consider the interactive implementation. I just want to add a link to the page. Before writing, you still have to build more macroscopically, rather than focusing on the details, after all, it can also reduce the probability of refactoring the code.

The above is about the content of this article "Vue Business case Analysis". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.