What is front-end engineering?

Now, as web services get more sophisticated and diversified, we’ve gone from WebPage mode to WebApp mode for front-end development. Front-end development is seen in some scenarios as just a chore, or an adjunct to a project, and not taken seriously as “software.”

In the transformation of the model, the front end is not the past to spell a few pages and make a few JQ plug-in can be completed. When engineering is complex, there are many problems, such as:

  • How to effectively collaborate with multiple people?
  • How to ensure the maintainability of the project?
  • How to improve the quality of project development?
  • How to reduce the risk of project production?
  • …

Front-end engineering is the use of the technology and method of software engineering to the development of the front-end process, technology and tools, experience, standardization, standardization, its main purpose is to improve efficiency and reduce cost, improve the efficiency of development in the process of development, namely reduce unnecessary repeat work time, while the front-end engineering is essentially a kind of software engineering, Therefore, front-end engineering should be studied from the perspective of software engineering.

Engineering in “front-end engineering” refers to software engineering.

How to do “front-end engineering”? Front-end engineering is to make front-end development system, I think it should be considered from four aspects: modularization, componentization, standardization and automation.

modular

To put it simply, modularization is to divide a large file into interdependent small files, and then assemble and load them uniformly.Copy the code
  • Modularization of JS

Prior to ES6, javascript didn’t have a modular system, which created a huge barrier to developing large and complex front-end engineering. A number of module loading schemes have been developed for this community, such as CommonJS, AMD and CMD.

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

  1. Use Webpack + Babel to pack all modules into a file for synchronous loading, or use multiple chunks for asynchronous loading;
  2. With system+ Babel is mainly divided module asynchronous loading;
  3. Use the browser<script type="module">Load.
  • Modularity of CSS

Although preprocessors such as SASS, Less, and Stylus implement file splitting of CSS, they do not solve an important problem of CSS modularity: global contamination of selectors.

Logically, a modular file should hide the internal scope and expose only a few interfaces to the user. With current preprocessors, importing a CSS module risks overwriting existing styles. While rewriting styles is an advantage of CSS, it is not conducive to multi-player collaboration.

To avoid global selector conflicts, you need to specify a CSS naming style:

  1. Ben style
  2. The bootstrap style
  3. …

But this is a weak constraint. So I agree with a sentence:

Rather than trying to avoid pain by telling people to follow rules, try to eliminate it at the tool level.Copy the code

From the tool level, the community has created three solutions: Shadow DOM, CSS in JS and CSS Modules.

  1. Shadow DOM is the webComponents standard. It will solve the global pollution problem, but many browsers are not compatible at the moment and are a long way off for us.
  2. CSS in JS is to discard CSS completely and use JS or JSON to write styles. This approach is radical, doesn’t take advantage of existing CSS technologies, and can be difficult to deal with issues like pseudo classes;
  3. CSS modules still use CSS, but let JS manage dependencies. It maximizes the combination of CSS ecology and JS modularity and is by far the best solution. Vue’s Scoped Style is another.
  • Modularization of resources

Webpack is powerful not only because it unifies the various js module systems, replacing browserify, requireJS, SeaJS. More important is its universal module-loading concept that all resources can and should be modular.

After the resources are modular, the advantages are:

  1. ** Dependencies are simplified. ** All CSS and images and other resources of the dependency of the unity of js route, without additional processing CSS preprocessor dependency, also do not need to deal with the code migration of the image merge, font images and other path problems;
  2. ** Resource processing integration. ** Loaders can now be used to do various things with various resources, such as complex vue-loaders and so on;
  3. ** Clear project structure. ** With Webpack, your project structure can always be represented by functions like this:dest=webpack(src, config).

componentization

Each fully functional structural unit that contains template (HTML) + style (CSS) + logic (JS) separated from the UI is called a component.

Componentization ≠ modularization. Modularity is simply the separation of code or resources at the file level; Componentization is the separation of the UI (user interface) at the design level.Copy the code

In fact, componentization is more important as a divide-and-conquer idea.

Everything on the page is a component. A page is a large component that can be broken down into several medium-sized components, which can then be broken down into several smaller components, which can then be broken down again until dom elements are broken down. The DOM element can be thought of as a component of the browser itself, as the basic unit of the component.

The idea of a traditional front-end framework/library is to organize the DOM first and then encapsulate some edible logic into components to manipulate the DOM, dom first. The idea of a componentized framework/library is to conceive components first, and then use dom as a basic unit to combine the corresponding logic to implement components, component first. This is the essential difference between the two.

Second, componentization is actually a further abstraction of object orientation in the form of template (HTML) + style (CSS) + logic (JS) trinity.

So in addition to encapsulating the components themselves, we should properly handle the relationships between components, such as (logical) inheritance, (style) extension, (template) nesting and inclusion, which can be classified as dependencies.

There are many componentized frameworks on the market, including Vue, React and Angular.

The canonical

In fact, standardization is a very important part of engineering, the quality of the specification in the early stage of the project will directly affect the quality of the later development.

Such as:

  1. The establishment of directory structure
  2. Coding standards
  3. Front and rear end interface specifications
  4. Document specification
  5. Component management
  6. Git Branch Management
  7. Commit Description specification
  8. Visual diagram specification
  9. …

automation

Much of the dirty work of front-end engineering should be left to automated tools.

  1. Icon to merge
  2. Continue to inherit
  3. Automated build
  4. Automated deployment
  5. Automated testing

The original address: www.jianshu.com/p/88ed70476…