Java Web project front end specification (deep decoupling of JS with namespace)

An excellent code architecture is not only easy to develop and maintain, but also an art of management and execution.

Over the past few years, I have experienced many projects and deeply hated the strong coupling between codes, nonstandard writing, poor maintainability and other problems. Here, after careful analysis, combined with their own coding habits, this paper summarizes a set of front-end writing specifications suitable for Java Web projects, and shares them with you.

PS: Thanks a Hai for his creativity. The post-processing is as follows (download the attached file):

1、 Project structure

This is not different from other projects. I separate the template to make it easier to analyze and understand:

Explain: JS mainly includes extensions (JS introduced from a third party), module (JS of the project module itself), lib (reference package, which can also be split here). Module contains JS in specific modules. Common.js is JS of the core namespace

2、 Common js

Explain that globals is a global namespace, and each module can define domains in this namespace (if you don't understand it, you can learn the namespace by yourself. This file can be written dead without specific understanding).

3、 Task js

This file is the JS (example) of the task module in my project in the module. Module level JS is generally a method to separate the relatively independent and important methods in the page. It is not recommended to take in all page JS.

Explain: module level JS mainly includes its own private properties and methods, as well as exposed JS properties and methods. Here, by default, all internal private items are preceded by "_", Finally, determine which methods and properties are exposed by constructing the method constructor.

4、 Page index jsp

Now let's take a look at how page JS and module JS are referenced in JSP. It's time to witness decoupling and.

Explain: the page needs to be common JS and task JS is introduced, and then initialized, so that the exposed methods and properties in the task module can be accessed.

Page JS recommends that all variables be sent in a variable group, which is convenient for maintenance.

The onclick and other methods of controls in the page are recommended to be bound uniformly in JS.

Summary: through the above configuration, the biggest advantage is that JS files are frequently introduced into the project, which eliminates the coupling between them, and the methods and attributes with the same name between different modules will not affect each other. Of course, the most important thing is to facilitate continuous development and maintenance, as well as artistic enjoyment.

This article adopts the annotation style I am used to. Of course, it can vary from person to person. My principle is:

1. Module introduction code mainly focuses on: module description, person in charge, relevant remarks, and double star comments

/**

*

*/

2. For the division of large areas under the module, it is customary to use double horizontal line notes:

//==================================================

//Description:

3. For the method notes in the area, not everyone is willing to write them in detail through past experience, so I think it's best to be simple and clear, and use ordinary notes:

//Code description

//Author's remarks and other information (unlimited)

4. For some important methods in the area, or if you want to distinguish and delimit between cells, use the star horizontal line

/****************************Description*****************************/

If you have good opinions, you can discuss them together. If you feel that the article is not helpful to you, you have the right to laugh it off.