First, front-end architecture code encapsulates, not design patterns, but conventions that are largely the result of programming language shortcomings.

1. Differences between users and developers

Look at the example

class ClassName {
	// The method name of the developer
	static _getBase64ByCb (file, cb) {
		// todo
	}
	// The user's method name
	getBase64 () {
		const file = this.file
		let base64 = ' '
		this._getBase64ByCb(file, function (base64) {
			base64 = base64
		})
		return base64
	}
}
// The user method added later
ClassName.prototype.getBase64s = function () {
	const base64s = []
	this.files.forEach(file= > {
		let base64 = ' '
		ClassName._getBase64ByCb(file, function (base64) {
			base64 = base64
		})
		base64s.push(base64)
	})
	return base64s
}
Copy the code

From _getBase64ByCb, getBase64, getBase64s three methods, basic can be seen

  1. From the name, you can distinguish who is used by the developer and who is used by the user
  2. The method used by the developer is for subsequent extensions such asgetBase64sMethods are not packaged at the beginning, and subsequent users expand on the original basis.
  3. why_getBase64ByCbIs it static? This is not a static method, but a simulationprotectedProperties.

1.1 Differences summary:

1> The naming method is reflected

  • The approach used by developers focuses on the process of execution
  • The methods used by the consumer focus on the results of execution

2> Properties and methods have different permissions

  • The methods developers use are protected, private, and $
  • The user uses methods such as prototype and static

3 > function

  • The method used by the developer, applied to the build
  • Methods used by the consumer, applied to the business (specifically, business code copy format)

2. Set rules for classes

  1. Class._fnProtected method
  2. Class._propretyProtected
  3. Class.prototype._propretyPrivate Private property or read-only property
  4. Class.prototype._fnPrivate methods
  5. Class.prototype.$fnThe framework and third-party plug-ins provide instantiation methods
  6. Class.prototype.$propretyThe framework and third-party plug-ins provide instantiation properties

This kind of rule is not written in the textbook, but is the default rule among JS programmers. (Do not understand, can not read the source code)

3. Abstract encapsulation and flexible invocation are contradictory

Abstract encapsulation and flexible invocation are contradictory. The balance between encapsulation and flexible invocation should be achieved, that is, which is encapsulation, depending on the specific business capabilities of each company. Here’s my personal encapsulation of the understanding that most of what I do is basically business, which is business driven.

  1. The business layer
    • Interface data, based on pure function encapsulation
    • UI interaction, process oriented
  2. The scaffold layers
    • Store (local storage)
    • Interface interceptor, verify login state (for users involved in security issues, to the back end to do, front-end inspection)
    • routing
    • Third, put the JS reference
    • One sided
    • Common components

First, the benefit of this point is that UI interaction does not change when the interface changes; UI interaction changes, interface data does not change; If both the data and UI interactions change, refactor. As an aside, this is the main job for most front-end jobs, and when skilled at this job, the need to jump out can’t meet this kind of screw job.

The second point, in fact, a lot of scaffolding is generally seeking gradual, the form is not fixed, as long as it can meet 6 points, how to build scaffolding, that is another big topic.