For so many years, as an 18-line front-end engineer, I have some personal understanding of the front-end specifications. For now, some of these specifications apply to more than just the front end, but basic solutions are built on top of the front end. Front-end specifications include not only code specifications, but also Git specifications and so on.

Git specification

Branch name specification

The master branch

  • The master branch is also used to deploy the production environment to ensure the stability of the master branch.
  • The Master branch is usually combined with the Develop and Hotfix branches, so you can’t change the code directly at any time.

Develop branch

  • Develop is a branch of development that keeps code up to date and bug-fixed.
  • The feature branch is created under the Develop branch when developing new features.

Feature branch

  • When developing new features, create a feature branch based on Develop
  • Branch naming: Feature/is a feature branch, naming rules: feature/user-module, feature/ Cart-Module;

The release branch

  • Release is the pre-online branch, and the release branch code will be used as the benchmark test in the release test stage

Hotfix branch

  • Branch naming: hotfix/ starts with the fix branch, and its naming rules are similar to feature branches.
  • Create hotfix branches based on the Master branch and merge the hotfix branches with the Master branch and Develop branch.

Submission information specification

Commitlint can be introduced to urge project members to commit professional Commit messages. Commitlint is used for Git hook callbacks. If you don’t want to write Githooks yourself, it’s easiest to use it with Husky.

Directory structure specification

The project organization specification defines how to organize a front-end project, such as the name of the project, the file structure of the project, the version number specification, and so on. Especially for open source projects, standardized project organization is even more important. A typical project organization specification is as follows:

  • Readme. md: Project description, this is the most important. Here you must provide key information about the project or an entry point to relevant information.
  • Changelog. md: Places the changes for each version, usually describing the changes for each version. It is convenient for users to determine which version to use. For details about the CHANGELOG specification, see Keep a CHANGELOG
  • Package. json: a front-end project must. Describes the current version, available commands, package names, dependencies, environment constraints, and project configurations.
  • .gitignore: Ignores unnecessary files to avoid committing automatically generated files to the repository
  • Gitattributes: Git configuration, some cross-platform behavior may need to be configured here, such as line breaks
  • Docs /: Detailed document of the project, optional.
  • Examples /: Example code for the project, optional.
  • Build: Project utility class scripts are placed here, not required. If you use the unified build tool, this directory is not available
  • Dist /: Output directory of project build results
  • SRC /: source directory
  • Tests /: Unit tests directory. According to the Jest specification, the __tests__ directory is usually in the same parent directory as the module being tested, for example :/ SRC tests/ index.ts a.ts index.ts a.ts copy code
  • Tests: Global test directory, usually for application integration tests or E2E tests, etc

For open source projects, these directories are often included:

  • LICENSE: indicates the project LICENSE
  • Github: Open source contribution specification and guidance
  • 3. CONTRIBUTING guidelines, which generally specify the specifications for contributions, as well as the basic organization and structure of the project
  • CODE_OF_CONDUCT: Code of conduct
  • COMMIT_CONVENTION: COMMIT_CONVENTION for submitting information, as mentioned above
  • ISSUE_TEMPLATE: Issue template. Github automatically recognizes this template
  • PULL_REQUEST_TEMPLATE: PR template

The above is a general project organization specification; how the source code is organized depends on the technology stack you use and team preferences. Here are some suggestions. We divide directories from naming principles, root directories, business logic, and so on.

1 Naming Conventions

  • Simple and clear (below 🙂
    • The SRC the source code
    • Img Image resources
    • Js JavaScript
    • Dep Third-party dependency package Development Package

The root directory structure is divided by function (as follows 🙂

  • SRC source code (logic)
  • Doc document
  • Dep Third-party dependency package
  • The test test

3 Divide folders based on service logic

  • SRC directory noun:
    • Common Resources
    • Public /static Static resources
    • Component components
    • View/TPL template file

The CSS specification

Naming conventions

1 BEM specification

BEM stands for block, element, or modifier, and is a front-end naming methodology developed by the Yandex team. This clever naming makes your CSS classes more transparent and meaningful to other developers.

The naming convention is as follows:

.block{} // blocks are commonly referred to as components or modules in Web application development. Each block is logically and functionally independent of the other.

.block__element{} // Elements are components of a block. The element cannot be used outside the block. BEM does not recommend nesting other elements within an element.

.block– Modifier {} // Modifier used to define the look and behavior of a block or element. The same block can look different when different modifiers are applied.

OOCSS (Object-oriented CSS) :

OOCSS represents Object Oriented CSS (OBJECT-ORIENTED CSS), which is a practice that applies object-oriented methodology to CSS code organization and management. The key to OOCSS is to improve its flexibility and reusability. This is also the most important aspect of OOCSS. The OOCSS proposition is to make CSS more extensible by adding more classes to the base component to extend the CSS rules of the base component.

Attribute order specification

When written, properties under a single style rule should be grouped by function, with a blank line between the groups. At the same time, it should be written in the order of Positioning Model > Box Model > Typographic > Visual to improve the readability of the code.

  • Positioning Model Layout method and position. Related attributes include Position, TOP, Z-index, display, float, etc
  • Box Model The Box Model. The attributes include: width, height, padding, margin, border,overflow
  • Typographic text, related attributes include: font, line-height, text-align
  • Visual Visual appearance, related properties include: color, background, list-style, Transform, animation

HTML specification

  • Make sure the tags are semantic, use the appropriate tags, and do the relevant things;
  • Design Dom hierarchies to avoid unnecessary layers; For example, you can implement effects based on the pseudo-elements before and after without adding additional tags.

JS specification

There are too many details about the JS specification to cover here. Several specifications are recommended:

Airbnb JavaScript Style Guide

Claims to be “the most reasonable way to write JavaScript code”. Airbnb’s code specification is probably the most popular JavaScript code specification on the Internet, with more than 60,000 stars on Github, covering almost every feature of JavaScript.

Address:

Github.com/airbnb/java…

Google JavaScript Style Guide

A JavaScript source file can only be called “Google Style” if it follows the rules here. Very domineering, go my own way, but also by many companies.

Address:

Google. Making. IO/styleguide /…

Idiomatic JavaScript Style Guide

A language-compliant JavaScript code specification.

No matter how many people are involved, all JavaScript code must look like it was written by the same person, regardless of whether they are in the same code base.

Another powerful and popular JavaScript coding specification. It also has big ambitions to regulate not only JavaScript but other languages as well.

All the code on the planet looks like it was written by the same person? It’s chilling to think about…

Address:

Github.com/rwaldron/id…

JavaScript Standard Style Guide

A powerful JavaScript code specification with built-in Linter and automatic code correction, no configuration, automatic formatting code. Low-level errors can be found early in the code. This code specification is adopted by many well-known companies, such as NPM, GitHub, mongoDB, etc.

Address:

Github.com/standard/st…

(This Github address is outrageously arrogant.)

VUE file specification

The official website has a very clear style guide that can be configured to suit your team’s needs.

Priority A: Necessary

These rules will help you avoid mistakes, so learn and accept the full cost of them. There may be exceptions, but they should be few and far between, and only if you are proficient in both JavaScript and Vue.

Priority B: Highly recommended

These rules can improve readability and the development experience in most projects. The code will still work even if you break it, but exceptions should be as few as possible and for a reasonable reason.

Priority C: Recommended

When there are multiple equally good options, choosing any one ensures consistency. In these rules, we describe each option and suggest a default option. This means that you are free to make different choices in your code base as long as you are consistent and have good reasons. Be sure to give a good reason! By embracing community standards, you will:

Train your brain to deal more easily with code you encounter in the community; Community code examples can be copied and pasted without modification; You’ll often be able to recruit new people who share your coding habits, at least when it comes to Vue.

Priority D: Use caution

Some Vue features exist to accommodate extreme cases or to help smooth the migration of old code. When overused, these features can make your code difficult to maintain and even a source of bugs. These rules are meant to sound the alarm about potentially risky features and explain when they should not be used and why.

The vue-eslint-plugin can be used to configure priorities or the details of a priority.

Code formatting tool Prettier

No matter what kind of code you write, Prettier removes all the styling from your code and then reprints it in a uniform format. Prettier has the following advantages:

  • Can be configured to change
  • Support for multiple languages
  • Integrate most editors
  • Concise configuration items

How do you use Prettier

Used in conjunction with ESLint

Prettier Prettier provides tools or plug-ins that work with ESLint that might be confusing to newcomers to what they do. Here’s a quick summary of Stackoverflow’s answer:

  • Prettier-eslint – A separate tool that basically prettier your code before eslint, in place of the eslint command Personally, I don’t recommend it.
  • Eslint-config-prettier – Unlike eslint-config-xxx, eslint-config-xxx does not share ESLint configuration, but turns off ESLint’s style rules so that they don’t conflict with Prettier. Using this configuration, prettier and esLint do not conflict with code. Be sure to place it last in the extends to avoid subsequent configurations that turn the rule on.
  • Eslint-plugin-prettier – Integrate prettier into an ESLint workflow, eliminating the need for the separate prettier command. 8. Code style problems Prettier finds as an ESLint rule, which shows up when running AN ESLint check and can also be fixed when –fix Prettier finds code style problems as an ESLint rule, which shows up when running an ESLint check and can also be fixed when –fix Used with eslint-config-prettier. Personally use basic OK, but since Prettier is not a single rule like ESLint, error display is not very friendly.
Together with
  • Used with Husky and Lint-staged

Document specification

Each project should have a standard document, and the different projects should have a similar structure of documents for unified management.

The above is my summary of the front end of the specification, I hope you criticize.