preface

For those of you with a lot of experience in development, this article may not be worth mentioning, but I’m talking mainly about object-oriented developers with little or no experience (preferably echarts). Here we talk about how to guide people to think about a problem. I take my project as an example to illustrate my thinking way and train of thought, which may give some inspiration to some people. What I said here is not right or wrong, what I said is not necessarily the right solution, purely a personal summary and share, I am also a little white. If there is a mistake, please forgive me, do not like spray!

example

Take the red box part of the interface as an example, implemented using Echarts, the graphics are relatively basic pie and bar charts. I think you all think that’s easy to do. Assuming you know the basic configuration items of echart’s two diagrams, is your first impression that this is so easy?

If your boss asks you for an estimate, you might blurt out an hour or two, or even less.

If I add a little caution here, and ask you to think as thoroughly as you can before you answer the boss’s question, have you, up to this point, changed a lot from what you just thought?

That’s the dividing line, but before we do that, you can think about it a little bit, and compare it to what I’m going to say

The overall layout

We know that there are two Echart diagrams, you can view them as two divs, on one line, and you can use

div {
    display: inline-block;
    width: 50%;
}
/** or **/
div {
    float: left;
    width: 50%;
}
Copy the code

To achieve, presumably your first reaction is also these two, anyway, I am.

If you think about it further, the screen will get bigger and smaller, and if it gets smaller, you won’t be able to fit on a single line, so you’ll have to break a line. Then, perhaps using Flex layout is more convenient and can be implemented intelligently without having to write your own media queries. However, when you actually write, you will find that the layout is messy and not up to expectations. Why? The reason is that the layout of echart graphics itself, due to the original function of echart normal display, there will be position and other layout CSS styles, we all know that using Flex layout, some of the layout styles of its child elements will be invalid. Therefore, this scheme is not feasible. Unfortunately, we have to deal with this situation through media inquiries.

Next, you see it in the diagram

Although these are two divs, they are not really next to each other. Aesthetically speaking, it would be better to use a blank space. So what do you do with this white space? A margin or a padding… That’s what I thought at first, but when it comes time to write code, it’s a hassle (-_ – I’m lazy) :

  1. Set a margin-left for the first div? Make a difference, add a class name, and set CSS.
  2. The width and margin values of the two divs are calculated to allocate the space ratio
  3. So small screen newline, there will be more than a margin-left, that media query processing it

The idea is very clear, implementation is also very simple. However, I eventually gave up, first I thought, fewer class names, the code is more beautiful; Second, I think the name is so boring, pseudo class? Can ah, but also to deal with whether you can really locate this, a whole environment of the code of the project itself, in fact, is very simple, but when placed in a complex code environment, all kinds of naming complex situation, less pseudo-class or relatively safe; Third, I don’t want to calculate; Fourth, the point is the point is, I think there’s a better way.

A better way to do it (still the class name, but I’m using the same class name for the project)

/** These two classes are probably familiar, but my project does not refer to boostrap, this is my own definition of the global class name **/
.pull-left {
    float: left! important;
}
.pull-right {
    float: right! important;
}
Copy the code

Going back to the diagram, I set the pull-left class name for the first div and the pull-right class name for the second div. But instead of width: 50%, they’re going to be smaller to leave as much white space as they need. (Of course, some of you may have thought of this layout from the beginning, but this is just a guide to a better way of thinking.)

Special case of graphics

As developers are well aware, it is not difficult to implement a PAGE on a UI diagram, but it is difficult. There are many circumstances, many unknowns, resulting in individual special cases or extreme cases. If the development time is 100%, then restoring the UI diagram (the normal case) takes 70% of the time, and 30% of the time is spent dealing with these extreme cases. In my heart, I feel very angry, clearly these special cases and extreme cases occur so rarely, lack of so much time to solve, and even make the code more complex, maintenance is not good. However, this is the reality and there is no way out. What we can do is to try our best to consider comprehensively before starting coding and make a plan from it, so as to avoid the embarrassment of changing the plan if we cannot write it in the middle of development.

So without further ado, what’s the special case here? Take the pie chart for example.

The situation a

To give you a general background requirement, how many groups of data are not fixed in the pie chart? What does that mean? There are six groups of data in the pie chart. Is the data of the six colors in the picture. The number of these numbers, we don’t know, could be a lot, could be a little bit.

What do you think after you know the basic background.

Since these numbers are unknown, we need to consider two extreme cases, one with very little data (i.e., one set of data) and one with a lot of data (infinity). What’s going to happen to the graph? Change now?

How much data will show up in the legend, what questions should be considered (progressive thinking)?

  1. No matter how many legends there are, the position of the legend should be vertically centered on the pie chart. Therefore, the top value of legend should be ‘middle’ instead of any other value. If there is a lot of data, will it automatically continue to stack down and remain vertically centered?
  2. The container containing the echart diagram must be set to a width and height to render the diagram. Therefore, the height cannot increase as the legend increases, so the light setting middle is still insufficient. Normally, since the height is set, a second column will be added automatically if the number of legends down reaches the height limit. But in this case, since there are two divs in a row and the width is set, it’s obviously free to go so far that only part of the legend is obscured.
  3. Unfortunately, faced with this problem, although the UI diagram does not take into account the case of multiple cases, and the product manager may not take into account the case, then maybe we need to decide on our own (better consult the product), but we need to be aware of this extreme. The solution is to take advantage of the legend paging feature provided by Echarts. Like this

Scene two

As stated above, how many sets of data are unknown, so the names of these data (little Red book published these…). It’s also unknown, and of course the length of these names is also unknown. So the question is, what if the name is long? Ideas:

  1. Echarts legend is very long, it will not automatically wrap, of course, choose canvas generated graph, and it is impossible to change the style. In our case, if it’s a long name, it’s going to go out of the screen. No!
  2. The UI diagram doesn’t tell you what to do in this case, right? However, we must have this awareness (repeated many times, I am not oneself), how to do? Truncation bai. As for the method of truncation, you can use the string phase, or you can use echart’s own method of truncation (check yourself, the impression is deeper).

  1. Does it cut it off? The horizontal position of fault, illustration consider good, if is it to the UI in figure the legend is to consider the placement of horizontal position, can really meet need to truncate, horizontal position put well, can appear even if you took away, but still show not to come out, directly by the parent layer to cut down the content of elements.
  2. Therefore, it is important to consider how much to truncate the legend based on the screen condition, and then adjust the horizontal position of the legend based on the truncated condition to avoid the above problems. Since it’s truncated and the user doesn’t know the real name, it’s natural to provide tooltips for truncated legends, using Echart’s tooltip feature

Three) Since data names can be very long, it is natural that the names on the corresponding tooltips can also be very long. There are two types of tooltips, one that floats over a pie chart and one that floats over a legend

  1. As shown, if the name is as long as the red box, the toolTip will be as long as the red box, and if unfortunately the tooltip level is not high enough, it may be obscured by other elements.
  2. For the tooltip of the legend, make sure the name is complete, or else the tooltip will be meaningless if you omit it. But you can’t make it that long. What do you do? So let him wrap it. As for wrapping, I’m not sure if I can set the width of this tooltip, but if I can, I can set the width, but the text inside will wrap. If not, just truncate the string, concatenate it with ‘\n’ and display it (I use this).
  3. For tooltips that hover over a pie chart, you can do the same or truncate method as described in the illustration, but it’s better to use line breaks and ask your product manager for details.
  4. So the question is, how wide do I have to wrap/truncate? Here’s an example of failure:

The last

Probably want to say on this point, in fact really want to deal with up, the details of things or a lot of, but I do not say more. I hope that after we get the UI diagram to get the demand, do not worry too much about the development immediately, or first understand the demand, consider all kinds of situations, in the code. I’m glad this article may have contributed a little to your thinking. Wish all the developers better and better ~~~