Two or three things to do with mobile page refactoring.

Now the front-end work, mobile status even more than the PC side, but also take advantage of time, to comprehensively summarize the mobile page refactoring considerations and some tips.

Not much to say, first of all, before the start of the project, the overall planning and preparation work.

I. Overall planning and preparation

1. Project Building Directory

Front-end projects are in full swing, the preparation of project development is becoming more and more complex, it project development is for more efficient development, that is, ease of use, high scalability, high maintenance of three aspects. When you build a catalog, you should analyze the specifics of the situation:

(1) Production environment and release environment directory (whether using packaging tools, compilers, etc., such as webpack, less, sass, Postcss, Babel, the project test error after the output publishing environment. ）

(2) Build tools catalog (gulp, Grunt, Webpack)

(3) Module loader catalog (Require, sea, Webpack)

(4) Test environment Catalog

(5) Real-machine debugging (note that browser-side previews are based on simulations of mobile device sizes, such as silverhalide and viewports, that do not fully mimic mobile devices.) ）

If you do not use an extra tool, this item can be ignored. Previously used gulp Browser-sync, will exist in Gulp's build directory.

(6) Main file directory (at the university when the front end may be in this directory, for self-deprecating ^_^)

Including CSS directory, JS directory, pictures, fonts and so on. In a small project, the loader for article (3) can also be included here, and this directory is flexible.

(7) Template and Routing and other logical layer directory (note: This is for front-end developers who use node. js as the backend language, if the backend language is PHP, Java, etc. can not be considered)

node. JS is a trend, the template directory takes Express+ejs as an example (I only use express), generally put the Ejs file in a directory, and the routing file is placed under the route directory, The Master file (App.js) is routed and then sent to a specific logical file for execution and then returned to the browser for rendering (the template for most backend languages)

2. Choose the right technology stack

There is no explanation for this, based on the highest possible development and execution efficiency, according to the company's requirements or personal preferences to choose.

3. Page unit selection and layout

The selection of units directly related to the effect of page rendering, according to my experience has the following options:

(1) Simple and brutal full use of media queries

Simple rough but really want what effect will have any effect, as long as you do not bother. This option can be wiped out in the front-end industry that pursues efficient development.

(2) Pure use of EM

The individual prefers to use EM at the root node to differentiate between the base font size of the PC and the mobile side when responding. However, there is no shortage of a good solution on the pure mobile side. However, because EM is calculated relative to the font size of the parent node when calculating the font size, it is particularly important to handle the fontsize size of the parent node, and there will be reaching bright once the processing is not good. Pure use of EM, the individual is not very recommended, because a node using EM not only depends on the parent node, but also affects the child nodes. The space for the standalone operation is slightly inadequate.

(3) Pure use of REM

But the idea is that a complete fluid layout is the best solution, but there are compatibility issues, such as Chrome's minimum font of 12px, but most other browsers have a minimum font size of 12 pixels. In real-Time debugging you will find that 12 pixels is the smallest font that normal users can tolerate, but using REM will make the font less than 12 pixels, so this choice requires developers to keep in mind the minimum font critical size.

(4) VW, VH (v-finger viewport here)

VW: Percentage of viewport width. such as 1VW is the 1%,VH of the viewport width, vmin the width of the viewport and the minimum value of the viewport height, vmax the same;

Using viewport units is a true choice for fluid layout, as it is not affected by any other factors other than the size of the viewport. The individual is optimistic about the follow-up development of the viewport units, after all, it is straightforward to design according to the response. But for a variety of reasons, the current use is not very broad, but in the local layout or solve specific problems often will play a finishing effect.

(5) em+ Media Enquiry

Recommended use, General unit operation using EM, specific operations using media queries.

(6) rem+ Media Enquiry

It is recommended to use the normal fluid layout operation using REM, specific operations (such as maximum minimum font, etc.) using media queries.

Collocation is the best choice, special projects need specific analysis, the above analysis and recommendations are based on the regular mobile-only project.

Two or three things to do with mobile page refactoring.