Interpretation of a text screen skeleton (rpm)

What is the skeleton screen

What is the skeleton screen it? Screen skeleton (Skeleton Screen) refers to the data before the page is loaded, it gives the user the general structure exhibits page (FIG placeholder gray), in getting the actual rendering of the interface data and then replace the contents of the page. Skeleton Screen past two years became popular loading controls, the interface is loaded during the transition effects on nature.
If we can about the profile page of the pre-show before loading, then load the real content and then gradually, so not only reduces the user's anxious mood, but also make the loading process becomes natural smooth interface, will not cause flicker or black and white pages for a long time . That's Skeleton Screen!

Skeleton Screen give people a page content "has been rendered a portion of" feeling, compared to traditional loading effect, to a certain extent, can improve the user experience.

Implementation skeleton screen

Currently generated skeleton screen technology program about three ways:

1. Written using pictures, svg skeleton or manually screen Code: Use HTML + CSS way, we can quickly complete skeleton-screen effect, but the face of demand for revision and change of visual design, we follow up on the screen changes to the skeleton will be very passive, repeat this mechanization of labor way at this time would be somewhat inadequate mobility;
2. By pre-rendering code written manually generate the corresponding screen skeleton: The scheme is made more mature vue-skeleton-webpack-plugin, by binding vue vueSSR screen assembly skeleton WebPACK written in the construction of the rendering of the generated pre-rendered DOM node and is inserted into the associated style html final output.

 // webpack.conf.js
 const SkeletonWebpackPlugin = require('vue-skeleton-webpack-plugin'); plugins: [ //... new SkeletonWebpackPlugin({ webpackConfig: { entry: { app: resolve('./src/entry-skeleton.js') } } }) ] 

The same premise of the program is to prepare the corresponding page of the skeleton screen components, and then generate the required pre-rendered skeleton screen DOM node, but directly associated with the program due vue related technology, under the framework of the front third of the world in today's environment, we You might need a more flexible and controllable programs;

3 hungry skeleton generation tools inside pages of it: the program through a webpack plug-page-skeleton-webpack-plugin way with seamless integration project development, are automatically generated in the screen skeleton made of very strong, and specially adapted skeleton can start screen UI interface, but in the face of complex pages there will be unsatisfactory, and the resulting screen skeleton node is based on the circumstances of the page itself structure and CSS, there is nested deeper, volume not too small, and only supports history mode.

 // webpack.conf.js
 const HtmlWebpackPlugin = require('html-webpack-plugin') const { SkeletonPlugin } = require('page-skeleton-webpack-plugin') const path = require('path') plugins: [ //... new HtmlWebpackPlugin({ // Your HtmlWebpackPlugin config }), new SkeletonPlugin({ pathname: path.resolve(__dirname, `${customPath}`), // 用来存储 shell 文件的地址 staticDir: path.resolve(__dirname, './dist'), // 最好和 `output.path` 相同 routes: ['/', '/search'], // 将需要生成骨架屏的路由添加到数组中 }) ] 

Our implementation

Then think about it, this piece looks the same screen skeleton is not a bunch of colored blocks and put together a page? Screen contrast existing framework program, the idea is a bit "short cuts" feeling. Still further reflection, the color analysis based on the current node to generate a page, the page is better to analyze segment JS node, generating a color block DOM operations meal makes up the skeleton screen. So the question is, how kind of accurate analysis page nodes, different node what should the patch generation do?

Since the skeleton screen represents the general structure of the page, you need to analyze the structure of the page using js. Prior to the analysis, we need to develop a rule to determine which nodes need to be excluded? What kinds of nodes need to generate a color block? How to generate the color blocks positioned like. Our initial set of rules are as follows:

1. Traverses only the visible region of the visible DOM node, comprising: a
   non-hidden element, element 0 is taller than wider, non-transparent element, the element content is not blank, the browser window element located within the regions of the visible and the like;
2. For the (background) image, text areas, single table, audio and video, the Canvas, defined features like block generates a color block;
3. Node page style used uncontrollable, so the size of undesirable correlation value style, available node width, height, distance from the absolute value of the viewport by getBoundingClientRect, calculates a width corresponding to a higher percentage of the current device as a color block unit, adapted to different devices;

Based on this set of rules, we began to generate skeleton screen:
First, determine a rootNode as the entry node, such as document.body, later extended at the same time easy to generate a page within the partial skeleton screen, thus recursively traverse the entrance and screening, preliminary exclude visible nodes.

function isHideStyle(node) { return getStyle(node, 'display') === 'none' || getStyle(node, 'visibility') === 'hidden' || getStyle(node, 'opacity') == 0 || node.hidden; } 

Next wherein determining element, it is determined whether the generation condition, for qualifying regions, "equal" to generate the color block corresponding region. "Equal," i.e., a region not eligible for distinguishing a particular element, without considering the hierarchical structure, without regard to the style, color blocks div unified generated according to the absolute value of the area from the viewport. This is so because the generated nodes are flat, relatively small size, while avoiding the extra read style sheet, the appearance of the screen skeleton is maintained by a detached style, this uniform manner so that the node generate the screen skeleton more controllable. Based on that "short cuts" the idea described above, the method of generating a screen skeleton is made of pure DOM makes up the color block.

The method of generating a color block:

const blocks = []; // width,height,top,left 都是算好的百分比 function drawBlock({width, height, top, left, zIndex = 9999999, background, radius} = {}) { const styles = [ 'position: fixed', 'z-index: '+ zIndex, 'top: '+ top +'%', 'left: '+ left +'%', 'width: '+ width +'%', 'height: '+ height +'%', 'background: '+ background ]; radius && radius != '0px' && styles.push('border-radius: ' + radius); // animation && styles.push('animation: ' + animation); blocks.push(`<div style="${ styles.join(';') }"></div>`); } 

Drawing color block is not difficult, analysis confirmed before painting is the real core of this program and difficult. For example, for large or complex page structure more page images, the mosaic picture is not the boundary area, the color produced will next block, appears not wholly satisfactory. As another example, a card that contains a lot of small block area in line with the conditions of generation, is still subject to block card inside the small subject generates a color block it? If the small subject, results may draw gives the impression that absolutely does not block a card, plus too many possibilities layout and style, greatly increased the uncertainty. And if the card block color block generated prevail, then we need to do special rules for card block.

At present, for the page structure is not particularly complex, not a full screen picture, the layout is not particularly "elegant" scene, the way has been the ideal framework can generate a screen. For those cases expected are far away, we offer two hook function for fine-tuning:

1. init function, before traversing nodes perform for interference delete nodes and other operations.
2. includeElement (node, draw) function can be specified when traversing the node, the method calls the draw custom drawing.

Screen skeleton can be generated by the above steps code directly in the browser.

Running in the browser

Since our starting point the program through a simple operation DOM traversal nodes on a page, according to the rules established by generating a corresponding region color blocks, forming the backbone of the page screen, the core code can run directly in the browser;

const createSkeletonHTML = require('draw-page-structure/evalDOM') createSkeletonHTML({ // ... background: 'red', animation: 'opacity 1s linear infinite;' }).then(skeletonHTML => { console.log(skeletonHTML) }).catch(e => { console.error(e) }) 

Screen skeleton generated automatically binding Puppeteer

Although this method has been screen can generate skeleton code, but still not enough automation, in order to allow the generated skeleton code for screen automatically loaded into the specified page. So, we have developed a package of CLI tools. The running tool Puppeteer by page, and the page evalDOM.js injection automatic execution script, the result of the execution code is generated screen skeleton inserted into the application page.

Our ideas about the program as follows:

Then take a look at how to use the CLI tool to generate a skeleton screen, up to just below four steps:

1. The overall installation, npm i draw-page-structure - g
2. dps init generates the configuration file dps.config.js
3. Modify the configuration to dps.config.js
4. dps start start generating screen skeleton

Simple steps, but not cumbersome configuration:

In general, you need to press their case to configure the project dps.config.js, common configuration items are:

• url: page address to be generated skeleton screen
• output.filepath: node file generation screen skeleton written
• output.injectSelector: screen skeleton inserted location node, the default #app
• background: framework screen color theme
• animation: css3 animation properties
• rootNode: True to generate a module skeleton screen
• device: device type, default mobile
• extraHTTPHeaders: add request header
• Before the start of operation of generating: init
• includeElement (node, draw): how to customize a node generation
• writePageStructure (html, filepath): callback screen skeleton node

Use detailed code and tools of the venue  Github ;

Preliminary results achieved

• Jingdong PLUS members in the official home page:

• Jingdong PLUS members in the official home page, generated by the program skeleton-screen effect:

• End of Baidu mobile home:

• Baidu home moving end, the program generated by the screen skeleton results:

to sum up

These are based on the automatically generated screen skeleton DOM embodiment, the core is evalDOM function. The program performance in many scenarios is satisfactory. However, too much possibility of page layout and combination of styles, in a variety of scenes you want to get the desired results, there is still a long way to go, but since it has been on the road, bravely forward it!