In Zhihu, ZHAO Yusen mentioned that front-end engineering has four aspects, including modularization, componentization, standardization and automation. I quite agree with him, and I have gradually summarized these aspects in my work

modular

Modularity is just the separation of code at the language level; Componentization is based on modularity, at the design level, the separation of the UI (user interface)

Modularization of JS

ES6 has now specified a module system at the language level that can completely replace the existing CommonJS and AMD specifications and is fairly simple to use

  • Webpack + Babel packs all modules into a single file to load
  • Systemjs modules are loaded asynchronously

Modularity of CSS

Currently, these three methods are used:

  • Use Vuejs’ Scoped style
  • []Adopt a naming style and recommend BEM
  • Uses a CSS preprocessor, currently using SASS

componentization

Componentization is based on modularity, because units of components can have templates, styles, and logic.

A component is a unit that can be made reusable by splitting the view (UI) that you can see. Vuejs single-file component is used in the component scheme

The canonical

In order to better implement the development, some specifications can be formulated

Coding standards

  1. Js uses ESLint and currently uses Google’s javascript Style Guide
  2. The CSS uses the corresponding stylelint
  3. Use EditorConfig, unify editor or IDE Settings such as js indent to 2 Spaces

Front and rear end interface specifications

Restful style and Swagger is used for interface description

For some interfaces to return status code or Chinese results, the front end should try not to judge the status, only display

Version control

Node Modules follow the Unix philosophy of “do one thing and do it well”. Therefore, a single upper-layer module may depend on many lower-layer modules, which may cause one of the lower-layer modules to change, causing the entire upper-layer module to crash.

The package version number in package.json should be written to death, unless updated due to a new requirement feature in a package

The directory structure

  • All file names in lower case, refer to
  • Adopt the proximity principle

Collaboration tools

This refers to the adoption of collaboration tools

  • Assignment, Trello/Gitlab Todo
  • Code repository, GitLab
  • Documentation, Gitlab Wiki/Trello
  • Product design, sketch drawing, inDesign document writing

Other specification

  • Development environment. Unix is recommended. It is unified with the deployment environment and many front-end tools are UNIX-friendly
  • [] codereview
  • []Git commit description specification, not specification does not allow commit
  • [] Writing specification of Chinese technical documents

automation

Environmental control

Docker automated deployment, cluster using Kubernetes (K8S)

Build tools

Currently webpack/rollup is used

  • Use SVG Sprite for ICONS
  • The browser automatically refreshes and hot loads
  • Compile intermediate languages such as ES6/7, SASS
  • Js, CSS compression and mixing
  • Compressed image, use base64 within a certain size
  • Generate hash value according to file content to achieve cache control
  • Implement load on demand, see modularity section
  • Umd packaging

Persistent integration

  • Gitlab/Git hook Implement hook
  • The Jenkin/Gitlab CI executes the appropriate build script and subscribes to the build results
  • []Package the build results and deliver them to o&M deployment

Project badge

Badges can be used to check the status of both open source and proprietary projects

  • Travis/Circle, continuous integration
  • Codacy, code review
  • NPM, providing version numbers, downloads, etc
  • Open source license, usually MIT
  • []Codecov, code coverage detection
  • []Saucellabs, cross-browser integration test

Front-end technology selection

Based on the above engineering process, the technology selection is as follows:

  • Based on library vue
  • Node middle layer KOA
  • CSS preprocesses SASS
  • Log collection Sentry
  • Jasmine, the front-end testing framework
  • Build tools Webpack /rollup
  • Debug tool chrome/ide/vue-dev-tools
  • Background processes manage PM2
  • Package management tool NPM/YARN
  • Json-rpc/Swagger/graphQL (query)

Front-end Project Configuration

css

reset

CSS reset Uses normalize.css

layout

Without considering compatibility, flexbox was used in one dimension, CSS grid was used in two dimension, unit rem/ VM VW. Box-sizing was changed to reduce the calculation of padding and border. For compatibility, use the grid layout scheme provided with Bootstrap3

The animation library

Hover, animate. CSS, Velocity

sass

Sass has Duplicate import problem

We have not solved it for the time being, but we can solve it as follows

  • Extract File
  • Webpack loader global
  • Webpack to recode (to be confirmed)
  • Cssnano (recommended)

The bottom line is don’t use references at all. Use variables or functions

Reference address ryerh.com/sass/2016/0…

webpack

noParse

Webpack spends a lot of time looking up a library’s dependencies, so using this parameter you can ignore parsing of known files in WebPack

For example, here we can confirm that vUE has no dependencies, configured as follows

Module :{noParse: {'vue': './node_modules/vue/vue.min.js'}}Copy the code

So we can use it in the project

import vue from 'vue'
Copy the code

alias

Provide an alias for the imported module, which reduces the time webPack has to find the location of the imported module, and also makes it easier to introduce common modules in our development

resolve: {
    alias: {
        'ui': path.resolve(__dirname, 'app/compontens/ui'),
        'fonts': path.resolve(__dirname, 'app/assets/fonts')
    }
}
Copy the code

This configuration allows us to avoid directory level considerations when we need to reference common components

import modal from 'ui/modal.vue'
Copy the code

CSS to use an alias in webpack, prefix the alias name with ~

@font-face {
    url( "~fonts/iconfont.woff") format('woff')
}
Copy the code

TODO tree shaking

Let WebPack understand the import mechanism of ES6, such that there are now two files

// utils.js
export function foo() {
    return 'foo';
}
export function bar() {
    return 'bar';
}
// app.js
import { foo } from './utils'
Copy the code

If you do not use tree-shaking, the app.js compilation output is

/***/ function(module, exports) { 'use strict'; Object.defineProperty(exports, "__esModule", { value: true }); exports.foo = foo; exports.bar = bar; // utils.js function foo() { return 'foo'; } function bar() { return 'bar'; } / / * * *}Copy the code

As you can see, it contains both foo and bar, packaging everything in utils. If you use tree-shaking, the output looks something like this

/***/ (function(module, __webpack_exports__, __webpack_require__) { "use strict"; /* harmony export (immutable) */ __webpack_exports__["a"] = foo; /* unused harmony export bar */ // utils.js function foo() { return 'foo'; } function bar() { return 'bar'; } / / * * *}),Copy the code

We can see which methods aren’t being used, and you can compress code with the –optimize-minimize parameter to weed out unused functions

// scripts" scripts": {"build": "webpack --optimize -- minimize", "seebuild": Function (t, e, n) {"use strict"; function r() { return "foo" } e.a = r }Copy the code

There are no bars anymore

babel

Create a.babelrc configuration file under the project. Currently, Babel provides the following functions

  1. Async loading in vue converts system.import to import()
  2. Use the tree shaking
  3. Use ES6/7 syntax and features

performance

TODO pictures

  • Preloading such as when a user enters an accountnew Image()Preloading images
  • The CDN service

Common front-end library

To be added

Back to Top