Introductory words

We all read a lot of articles, a lot of articles tell you, how to write SAO operation, vue has what API, es6 how to use. There really isn’t a systematic, targeted way to tell you how to do a project with VUE. So I plan to start writing this series of articles, hoping to use my experience, my insights, to get a beginner and a beginner up to the standard of developing a full project on their own.

Front knowledge

This article is not about VUE documentation, so you need to know something about VUE, not to mention JS and HTML.

Start a project

When we start a project, we should have at least two pieces of information: requirements and the design draft. If any of them are missing, I suggest you check with the person concerned. Let me break it down:

demand

Requirements may come from within or outside the company. For the internal needs of the company, in fact, it is often easier, because some of the business you may have been exposed to, such as your previous XX system is terrible, need to update. External requirements are more complex because users are often unpredictable, so it’s important to maintain communication and flexibility in case requirements change.

Be sure to communicate more and understand the requirement thoroughly. My advice is to think of yourself as a user and understand the internal meaning of the requirement so that it can be better fulfilled.

The design draft

There’s nothing to be said for this, but restoring the design is a fundamental part of every Web front end. My layout skills aren’t that great either, but I still have some lessons to share.

  • Elastic box is the mainstream at present, whether compatibility, or functional enough, it is recommended to skillfully use, the Holy Grail layout is very common in the mobile terminal.
  • Try to put images in CSS so they load faster and are a better experience to use.
  • Each area should be wrapped in a separate label, which I call isolation

1. My understanding of VUE

I think the two most important parts of vUE in the project are responsiveness and componentization.

responsive

I think of responsiveness as the unification of data and UI state. Therefore, when our app is particularly dependent on data changes in the UI, it is recommended to choose a framework like VUE. How to design responsiveness, which I’ll talk about later.

componentization

Componentization is a kind of necessity, is the destiny of the front end. It turns the front end on its head. Like I used to, there was always a module a page, and then jquery a shuttle, were there components back then? Yes, after all, jQuery also has a load method, but components are not that important.

I really worked with components when I was using VUE,.vue files, which are SFC. This is when you realize how convenient components are and how much redundancy they reduce. But this also introduces a new problem: component splitting. I think the number one reason many people get stuck with a requirement is because they don’t know how to break it down.

2. Component splitting and combination

Break up

Based on my experience, I categorize components into display components, functional components, and container components.

  • Display components: There is nothing to be said for displaying information. There are no methods or data in this type of component.
  • Functional component: This is the most common component, mainly the function of the module.
  • Container component: is special, in my real project, can be a starting point for getting data, or can only serve as a connection.

So component splitting is the process of breaking your design into three components based on functionality and combining them into one product.

So how do you break it up? This is my experience.

Step 1: Identify container-level components. In fact, this step is the same as our usual layout, there are several pages, or several large modules, according to the function of the connection to allocate containers.

Step 2: Divide functional components into container components and tease out the data flow. For VUE, data-driven pages, data flow is clearly the heart of the system.

Step 3: Partition the display components. Display components are not very important, but I have always been a principle: reduce the number of functional components, more display components.

Why do you do that? Because the display component tends to have no state, or its state depends on a component outside of itself, it’s like a puppet and naturally more controllable. However, as there will be data and methods in functional components, their state may be modified at any time, which is obviously difficult to control.

combination

Composition of components is really communication of components. Anyone who has used vUE should know at least 2 props and $emit,vuex.

Props is the parent and $emit is the parent. There’s nothing to say about this, but I can introduce some of my favorite tips.

If you don’t need to do anything complicated, write $emit directly to templete.

<button @click="$emit('handleClick',detail)">{{missionBtnText}}</button>
Copy the code

Props requires type validation

 props: {
    detail: {
      type: Object,// The type of this props must be specified. If any other type is passed, an error of required will be reported:true}},Copy the code

Hide the props render to the page and add this configuration to the child component

 inheritAttrs: false
Copy the code

I’ll just say one thing about Vuex. For medium and large projects, use it when you need to share a lot of data at the same time

3. Response

The core of responsiveness is data, the data in VUE. Reasonable design of data, not only to facilitate the current use, but also to facilitate the later expansion.

What I mean by reasonable is to reduce the data in data.

The variables in data return are actually traversed by vue, and the dependencies are collected. The more you define, the deeper the hierarchy, the slower the natural traversal. So you have to sort out what’s fixed, what’s just for display, or what’s circular. That’s when you need the next one

Make good use of the computed

Computed is really good stuff, like the ones above that just show content, and you can encapsulate it into a JS.

// a.js
export default {
  a: 'hello world'.b: 'target:test'
}
Copy the code

It is then referenced in a Vue file

import a from './utils/a'
export default {
  computed: {
       contentA () {
      	 return a
       }
  }
}
Copy the code

ContentA can then be used in a template or other function, which defines a data.

Ensure data types

In Vue3.0, typescript will greatly improve this, but for now in 2.6 I still recommend that you define data with data types. For example, 1, you don’t want to define it as ‘1’, for example, if the return value is an array, you don’t want to define it as an empty object. Otherwise, sometimes it’s really troublesome to make a mistake.


Recently, I was also recalling the project process of more than a year, how I learned from a rookie to find a job. At that time, I took over a legacy project, how confused, docking a payment, how clueless. I hope I can use my experience to make progress together.

Welcome to follow my public number