Small Web page packaging optimization (bottom)

Before we pushed a small Web project packaging optimization article, (link), we used a period of time, in the process we have been thinking, how to make the structure better. So we have modified a version, to improve the place and possible problems, in this version of the optimization. Little friends, can't wait? Well, let's cut the crap and get to the chase ^_^.

I. BACKGROUND

Before, there are some hybrid pages in the app side and some landing pages outside the end, usually a single one or two small pages, not the so-called large front-end applications, relatively fragmented, interactive and relatively simple. If you use Vue or react, a little kill chicken with sledgehammer meaning, no need, and the business code is less than the framework code, the performance of the page load, the efficiency is not high.

So in order to manage these pages together, we create a project on our own Gitlab, as a collection of these small pages, with many directories, each representing a small project. Everything seems to be normal, all very orderly ...

Two months ago, we found in the group, these pages have experienced more than a year of time, has been iterative a lot of small projects, because the specification is not very perfect, the page is also written in a variety of, especially packaging building tools, there are FIS, there are glup, there are webpack and so on. This undoubtedly to the back of the students, brought trouble, so we produced the first version of unity. We have unified the use of packaging tools, and then streamlined the code, optimized the hierarchy, so that each directory structure is unified, formed a specification.

However, recently, we are thinking, although the directory structure is unified, but if you encounter a component upgrade, such as our Jsbridge upgrade, then it is not a headache to upgrade the dependencies of each project again. If the project directory is more than 20, it is necessary to manually upgrade 20 pages, causing trouble not to say, but also very error-prone. So, practice it, let's optimize it together.

Second, Brief introduction

1. Schematic diagram

Speaking of the principle, have to say webpack, this transformation is based on Webpack to package the compilation, Webpack mainly help us do these things, but also webpack the most basic functions, such as:

As we all know, Webpack is a full English document, here to the English poor friends to paste a Chinese version . Is the disassembly diagram for the entire project.

2. Project Structure

Needless to say, everyone is a program ape, first on the code. I put the project structure code on my own GitHub, and later, for example, Zzdownload is one of many small projects. In order to facilitate people to view, the project directory structure as follows, specifically please move here!

Iii. use of methods and scenarios

1. How to use

-Installation

NPM Install

　

Nodejs environment is the premise, I think we should have no doubt, this does not do too much explanation, you know ~

-Configuration

Module.exports = {       "name": "Zzdownload",         "Vendor": [' Es6-promise/auto ', ' axios ', ' mustache '],       "pages": [{           "name": "Download",           "template": "/download/download.html",           "entry": "/download/download.js",           " Output ":" Index.html "       }"};

　　

The directory in each SRC can be called a standalone small project. In each small project, you need to have a configuration for this project, that is, config.js. Or take zzdownload as an example, see above configuration, can be a single landing page, can also be multiple pages. The configuration is not too much elaborated here, and will be explained in detail later.

The Debug page can be used

npm run dev 项目名

Wait for the page to be completed, need to pack the line, execute

npm run build 项目名

In our git example, we execute **NPM run build zzdownload**. The code for compiling the output is then in the **dist/zzdownload** of the root directory.

* * As for the internal business implementation of the page, whatever you! **
* * As for the internal frame of the page, whatever you want! **
* * For the internal directory structure of the page, whatever you want! **

We are so human, business code with you diy! Do not interfere with personal habits, we just compile the code to pack the porters!

2. What conditions to use

• Reduced the size of the output code

Using the facts to speak, take the above project as an example, I made a turn to download the landing page zzdownload. Looked at the next Dist output page, altogether 75k. is not obvious, the whole page is less than 80k, I think it is 2G environment, loading up is not very slow it.

• It is not recommended to build a complex single page application

Speaking of which, many alumni asked, if we use a framework like React/vue, to build the whole project, each small page is a route, that can not achieve the same effect? Wouldn't it be convenient to upgrade the JDK or solve some of the public component problems?

In fact, the short-term look like this seems to be no problem, but considering a period of time, there may be a lot of small pages, then whenever a new small page, need to compile the entire project, at that time the project output code is not dozens of k size can be solved. And just add a small page, but need to complete the package compilation and on-line, which for the other small pages within the project, or relatively risky.

Although we support the complex single page, but in order to streamline the output code, there is no introduction of Babel, such as React/vue this construction of complex applications, not ES6, development is not easy, for obsessive-compulsive disorder of me, still quite unacceptable. and complex page application, itself will rely on a lot of libraries or plug-ins, which is also in order to streamline the starting point is against. If you have a complex single-page application of the project, it is recommended or vue-cli comparison to the convenience, but also faster.

Four, the principle

1. Code Execution steps

• We have a reference to the NPM command, and the project name is the parameter.
• The parameters are passed through the Webpack and the corresponding directories in SRC are found according to the parameters.
• Read the Config.js file in the directory, the root attribute includes name, vendor, and pages, respectively, corresponding to the project name (which may later be optimized for this parameter, only with directory name and parameter matching), public dependency, page collection (multiple pages, array with multiple items).
• By traversing the various properties of Config, Config can be understood as a large set of parameters, the result of which is passed into the entry and plugins properties of Webpack, and a complete webpack configuration is generated.
• When everything is ready, it is Webpack's own compilation package. Wait a few seconds and you'll see the output code in the dist!

2. Parameter description

Module.exports = {"Name": "Zzdownload", "Vendor": [' Es6-promise/auto ', ' axios ', ' mustache '], "pages": [{"Name": " Download "," template ":"/download/download.html "," entry ":"/download/download.js "," Output ":" Index.html "   }]};

　　

Take the above configuration as an example.

• Name: For the page name, you can understand the role of an ID, multiple pages in the same project, name cannot be the same.
• Template: An HTML path to the output page of a page portal
• Entry: JS file path for page entry
• Output: The file name of the output page
• Name: The project name for this project needs to be the same as the directory in SRC, used as a directory for Webpack compilation, and subsequent consideration of whether this parameter can be optimized, because the directory can be found by executing the parameters of NPM run.
• Vendor: Public dependencies for this project, such as templates we rely on (such as mustache), sending requests (such as Axios), can be configured here.
• Pages: A collection of pages that, if multiple pages, configure multiple items of an array.

PS: It is configured as a single page, and multiple pages are configured with multiple items in the pages array. Each entry needs to have HTML and JS entry, each page also produces the page name (that is, output). The entire project module is named name, and the overall third-party functionality is dependent on vender. Note that the dependency here refers to the dependency of each small project, not the entire large project.

V. Summary

1. Advantages

• Dependency issues

All current project dependencies are unified and depend on the configuration of the most externally package.json. Even if there is a dependency on the upgrade, just modify the version in Package.json, and then compile it OK.

• Output code

The output code of each project is unified into the root directory of the Dist, the dist will be divided according to the project directory in SRC, and one by one corresponds. Enter your own output project directory with HTML files and static directories, and then deploy them to the test server and CDN, respectively.

• Personalized Page Entry

This configuration applies to both single-page and multi-page configurations, depending on the entry of the profile. The external webpack are unified, but each project needs its own configuration file to personalize the DIY. So, whether you are based on what technology station, vue/react or early require/jquery, all clean sweep.

2. Role

This optimization is mainly for scattered small pages, easy to manage the collection of small pages. If each small page as a project, not only caused the number of projects flooding, inconvenient management, but also. If in the absence of documents, the consequences can be imagined, estimated that each of the students will have complaints.

Personally, I think it's a good way to try out this form of a page that's not as interactive and iterative as it is, like some operations pages.

Speaking of which, we have to stop for a moment, thank you for seeing this. For this kind of solution, we will continue to optimize, with a new upgrade I will share with you. Please also see the great god of this article more valuable advice, we will continue to refuel efforts ...

Small Web page packaging optimization (bottom)