Aurora Notes丨On the one-to-one restoration of the design draft on the large data screen

Aurora Senior Engineer——Zeng Huiteng

Preface

When the 5G technology just came out and stood on the vent, good guy, it was simply overwhelming, and everything could be 5G. At that time, many front-end people believed that 5G was the future of the front-end. At that time, I couldn't understand the internship, but I was shocked. I was thinking, what does 5G have to do with the front-end? After thinking about it for a long time, I couldn't fall asleep at night. I really couldn't sleep. I could only see the two words between these words, "working overtime".

Haha, the above is an active joke. In fact, the next generation of communication technology will have a great positive impact on our daily lives. Large data screens have also been developing, and have been working hard to get rid of flashy labels, in order to highlight the value of data.

Back to development, what if we need to implement a large-screen data application that can adapt to all screens? Let's first take a look at a few implementation schemes to expand our thinking.

Solutions on the market

Use width percentage directly for adaptation

This kind of scheme needs to accurately calculate the value of the corresponding percentage, usually this value is not easy to calculate, and in many cases a certain height needs to be given. Such an approach is not to say that it is impossible, it can only be said that 2021 is now, and there are many better implementation schemes than this.

Use @media media query to adapt to various screens

When I first came into contact with the media query of css3, I felt that this attribute was too timely. It just corresponds to the popularization of mobile smart phones and provides a very good solution for the adaptation of different screens. However, the "breakpoints" set in the media query are discrete, and the large-screen interface may be stretched in actual applications, and the interface cannot be displayed on a 100% basis. And there will be a lot of adaptation styles to be written, which is a bit laborious.

Use postcss to convert px into rem through a series of calculations to achieve adaptation when packaging and compiling

This solution essentially uses the feature of the relative length unit of rem. For example, if the font size of the root element of the page is 16px, then 1rem is equal to 16px. Of course, the default value of the root element of the page is 16px. If we set it to 12px, then 1rem is equal to 12px.

At this time, we can know that the height and width of the design draft are fixed, while the height and width of the screen will change. But we can calculate the ratio of the design draft to the screen. In this way, the following key formula can be derived:

The width of an element displayed on the actual screen = (actual screen width / design draft width) * the width of an element in the design draft

In the project configuration, we apply the ratio of the actual screen to the design draft to the root element of the page. If this ratio is 1/2 or 0.5, then 1rem is equal to 8px at this time, and then configure the root element font size in postcss to 8px In this way, in the development of the code, the dimensions marked in the design draft are used directly.

postcss needs to be configured as follows

However, there is a problem with this solution, that is, although the design draft can be displayed proportionally, what should I do if the screen height and width are changed? The configuration of postcss converts the relevant rem unit during the packaging and compilation process, so it cannot cope with this situation.

In summary, some of the above methods are not intuitive enough, some are difficult to maintain, and some cannot adapt to all screens. So is there a way to solve this series of problems? The answer is yes. We need to make some improvements to the third plan based on the actual situation. Let's first take a look at the effects that need to be achieved.

Need to achieve

Can fit all screen ratios
One-to-one non-destructive restoration of the design draft, both in proportion and size
Convenient to maintain, it is best to directly use the values marked in the design draft

analyze

To achieve this effect, we need to remove the relevant conversion of the unit during the compilation phase, so that the relevant conversion can be dynamically calculated. And sometimes when the width fills the screen, in order to keep the ratio unchanged, the height does not necessarily wait to fill the height of the screen. On the contrary, when the height fills the screen, the width may not be filled. These situations need to be considered.

Unified numerical conversion

After the above preparation, it is not difficult to find that the fontSize of the root element of the page can be directly used as a ratio. Observe the following transformations. If this ratio is 1000/2000 or 0.5, then the root element fontSize is set to 0.5px, and 1rem is equal to 0.5px. In this way, if the size of an element in the design draft is 2000px, then we can set it to 2000rem in the code. So what is displayed on the actual screen is 2000*0.5=1000px. Perfect, you can directly use the value of the design draft, although the unit needs to be changed when writing.

Considering that the height or width does not fill the screen, we can add some judgments to supplement it.

When the height or width does not fill the screen, the blank part can be filled with the same theme color or background.

The adaptation is basically done here, but in addition to restoring the size ratio, related animation effects are also a very important part.

svg components and animation

In large-screen applications, it is recommended to use svg vector graphics as much as possible, so that resolution problems can be completely avoided, and svg graphics also play an important role in animation special effects.

For example, the following is the setting of the path tag in a svg component, where the containerBox is bound to the onSize event, so that the path can dynamically adjust the size of the border according to the size of the content.

Among them, the strokeDasharray and strokeDashoffset attributes are the key to controlling the border animation.

The effect of this animation frame is relatively simple, just a gilt effect with highlights flowing along the border. If it is some complex animation, you can use TimelineLite/TimelineMax and other timeline tools to create.

Concluding remarks

Up to this point, writing a large-screen data application does not seem to be a difficult task. The effects to be achieved have all been achieved, and there is no need to worry about related problems when developing related large-screen products. Of course, this is limited to 2D pure display large-screen applications. If it is a 3D interactive data application, it is another topic.