Earlier we posted a small Web project package optimization article, (link), which we used for a while, and we were thinking about how we could make the structure better. So we reformed a version, the place that can improve and the problem that may appear, carried on optimization in this version. Can’t wait, guys? Well, let’s talk no more and get to the point

The background,

Before, there were some Hybrid pages and some landing pages outside the end of the App, which were generally a single one or two small pages, rather than the so-called large front-end application, relatively scattered and simple interaction. If you use Vue or React, it’s not necessary, and there is less business code than framework code, which is not efficient for page loading performance.

So in order to unify these pages, we created a project on our GitLab as a collection of these small pages, with many directories, each representing a small project. Everything seemed normal and orderly…

Two months ago, our team found that these pages have gone through more than a year and iterated many small projects. Due to the imperfect specification, the pages inside are also written in a variety of ways, especially packaging and building tools, such as FIS, GLUP and Webpack. This certainly caused problems for the students who took over later, and so we had the first version of unification. We unified the use of packaging tools, then streamlined the code, optimized the hierarchy, and unified each directory structure into a specification.

Recently, however, we have been thinking that although the directory structure is unified, if there is a component upgrade, such as the JsBridge upgrade, then it would be a headache to upgrade the dependencies of each project. If there are more than 20 project directories, you have to manually upgrade 20 pages, which is troublesome and error-prone. So, practice and let’s optimize.

Two, a brief introduction

1. Schematic diagram

Speaking of principle, we have to talk about Webpack first. This reform is packaged and compiled based on Webpack. Webpack mainly helps us to do these things, which is also the most basic function of Webpack, as shown below:

As we all know, Webpack is an All-English document, here is a Chinese version for those who are not good at English. Below is a breakdown of the whole project

2. Project structure

Cut the crap. We’re all code monkeys. Code first. I put the project structure code on my Github and ZZDownload is just one example of many small projects. For your convenience, the project directory structure screenshot is as follows, please go here for details!

Three, the use of methods and scenarios

1. How to use it


      
    
       
  1. npm install
    2. 
      
Copy the code

      
    
       
  1. Nodejs environment is the premise, I think you should have no doubt, this will not explain too much, you know ~
    2. 
       
    3. 
       
  3. - the configuration
    4. 
      
Copy the code
    module.exports = {

      
    
       
  1.     "name": "ZZDownload",        
    2. 
      
        "vendor": ['es6-promise/auto', 'axios', 'mustache'],
        "pages": [{
            "name": "Download",
            "template": "/Download/Download.html",
            "entry": "/Download/Download.js",

      
    
       
  1.          "output": "index.html"
    2. 
       
  2.      }]
    3. 
       
  3. };
    4. 
      
Copy the code

      
    
       
  1. Each directory in SRC can be called a separate small project. Within each small project, there needs to be a configuration for that project, config.js. Using ZZDownload as an example, see the configuration above, which can be a single landing page or multiple pages. The configuration is not explained here and will be explained in detail later.
    2. 
       
    3. 
       
  3. The debug page is available
    4. 
       
    5. 
       
    6. 
       
  6. NPM run dev Project name
    7. 
      
       

      
    
       
    2. 
       
  2. When the page is opened, it needs to be packed online and executed
    3. 
       
    4. 
       
  4. NPM Run Build project name
    5. 
      
           

      
    
       
  1. In our git example, we run ** NPM run build ZZDownload**. The resulting code is then compiled in the root directory **dist/ZZDownload**.
    2. 
       
    3. 
       
  3. ** As for the internal business implementation of the page, suit yourself! **
    4. 
       
    5. 
       
  5. ** As for the dependency framework inside the page, suit yourself! **
    6. 
       
    7. 
       
  7. ** As for the internal directory structure of the page, whatever! **
    8. 
       
    9. 
       
  9. We are so humanized, business code DIY with you! Do not interfere with personal habits, we are just code compilation package porters!
    10. 
      
Copy the code

2. Which situations to use

If we use a framework like React/Vue to build a whole project, and each small page is a route, we can achieve the same effect. Wouldn’t it be convenient to update the JDK or fix some common component issues?

In fact, in the short term, this seems to be no problem, but considering that after a period of time, there may be a large number of small pages, so every time you add a small page, you need to compile the whole project, at that time the project output code is not tens of K size can solve. And just add a small page, but need the whole package to compile and go live, this for other small pages in the project, or relatively risky.

Although we support complex single pages, in order to simplify the output code, we did not introduce Babel. React/Vue, a complex application building project, was not easy to develop without ES6, which was quite unacceptable to me as an obsessive person. And complex page applications themselves rely on many libraries or plug-ins, which goes against our goal of simplicity. If you have a complex single page application project, it is recommended that VUE-CLI is more convenient and faster.

  • Reduced the size of the output code

Speaking of facts, for example, I made a roundabout download landing page ZZDownload for the above project. I looked at the page of DIST output, 75K in total. Obviously, the entire page is under 80K, so I guess it’s not too slow to load even in a 2G environment.

  • It is not recommended to build complex single-page applications

Fourth, the principle of

1. Code execution steps

We pass in the NPM command, and the project name is the parameter.

Upload the parameters transparently to Webpack and find the corresponding directory in SRC according to the parameters.

Read the config.js file in the directory, root attributes include name, vendor, pages, corresponding to the project name (this parameter may be optimized later, only the directory name and parameter match), public dependency, page set (multiple pages, multiple numbers).

By iterating through the properties of config, which can be understood as a large set of parameters, the traversal results are passed into webpack entry and plugins properties to generate a complete webpack configuration.

With everything in place, it’s time for WebPack’s own compilation package. After a few seconds, you can see the output code in dist.

    2. Parameter Description

    
      
      
       
    1. module.exports = {
      2. 
       
    2.     "name": "ZZDownload",
      3. 
       
    3.     "vendor": ['es6-promise/auto', 'axios', 'mustache'],
      4. 
       
    4.     "pages": [{
      5. 
       
    5.         "name": "Download",
      6. 
       
    6.         "template": "/Download/Download.html",
      7. 
       
    7.         "entry": "/Download/Download.js",
      8. 
       
    8.         "output": "index.html"
      9. 
       
    9.     }]
      10. 
       
    10. };
      11. 
      
    Copy the code

    The preceding configuration is used as an example.

      • Name: indicates the name of the page. It can be understood that it acts as an ID. The name of multiple pages in the same project cannot be the same.

      • Template: the template of the page entry, which is the HTML path to the output page

      • Entry: js file path of the page entry

      • Output: indicates the file name of the output page

      • Name: the project name of this project. It needs to be the same as the directory in SRC, used as the directory for webpack compilation.

      • Vendor: Common dependencies for this project, such as the template we rely on (like Mustache), sending requests (like Axios), etc., can be configured here.

      • Pages: belongs to the collection of pages, if multiple pages, configure array multiple.

      PS: the above configuration is a single page, multiple pages only need to configure multiple items in the Pages array. Each entry should have an HTML and JS entry, and each page should also have a page name (i.e., output). The module name of the whole project is Name, and the overall third-party function dependency is Vender. Note that by dependency, we mean each small project dependency, not the entire project dependency.

      Five, the summary

      1. The advantage

      • Depend on the problem

      Currently, all projects have uniform dependencies, relying on the most external package.json configuration. Even with dependency upgrades, just change the version in package.json and compile it.

      • Output code

      The output code of each project is unified into the dist of the root directory, which will be divided according to the project directory in SRC and corresponding to each other. Go to your output project directory, which contains the HTML file and static directory, and deploy to the test server and CDN respectively.

      • Personalized page entry

      This configuration applies to both single and multiple pages, depending on the entry of the configuration file. External Webpacks are unified, but each project needs its own configuration file to personalize DIY. So, whatever technology you’re based on, vue/ React or earlier require/jquery, get it all.

      2. The role

      This optimization is mainly for scattered small pages, easy to manage the collection of small pages. If each small page as a project, both caused the flood of project number, inconvenient management, and will. If the missing documents, the consequences can be imagined, it is estimated that every student who took over will complain.

      Personally, I think this kind of trial is a good way to interact with pages that are not complex and require quick iteration, like some operational pages.

         

      And with that, we’re going to stop for the moment, and thank you for being here. For this scheme, we will continue to optimize, and I will share with you any new improvements. Please also see the great gods of this article more valuable advice, we will continue to refuel efforts……