从ui图到开发页面该有的考虑

前言

开发经验满满的前辈们，此篇文章或许对你们来讲并不值得一提，这里说的主要面向对象是小白，或者欠缺点经验的开发者们（懂echarts的更佳）。这里聊得是引导大家如何去思考一个问题，以我所在项目为例子，阐述我的思考方式和思路，也许对于某些人来讲，能给予一些启发。这里说的没有对与错之分，我说的也未必都是正解，纯粹地一个个人总结和分享，我也是一个小小白。如有错误请多见谅，不喜勿喷！

例子

以这界面中红框部分为例子，用echarts实现，图形都是比较基础的饼图和柱状图。想必大家都觉得这个很好实现吧。假设你知道echart的这两种图的基本配置项，大家的第一感觉是不是觉得，这个so easy？

假设你的老板叫你评估个时间做出来，可能你会凭感觉地脱口而出，1-2个小时吧，甚至更短？

如果我在这里加个提醒，叫大家尽可能去考虑全面再去回答老板的问题，是否，直到这里，你跟刚刚的想法发生了较大的变化？

这是分界线，在这之前，大家还是可以好好考虑全面一下，跟接下来，我要说的，对比一下

整体布局

我们知道，这里是有两个echart图，可以看成两个div，放在一行，可以用

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

来实现，想必各位第一反应也是这两个吧，反正我是的。

进一步去想，屏幕会变大缩小，如果缩小到很小的话，相比两者挤不下一行了，这时就要换行。那么，可能用flex布局，更加方便，都不用自己写媒体查询就可以智能的实现了。
然而，等到你真正去写的时候，会发现，布局乱糟糟，达不到预期，为何？
原因在echart图形本身的布局上，由于原本让echart正常展示的功能，会存在position等布局css样式，我们都知道，使用flex布局，其子元素的一些布局样式会失效。因此，这种方案不可行。很遗憾，我们还是通过媒体查询去处理这种情况吧。

接下来，在图中看到

虽说这是两个div，但是其实并没有紧挨在一起的，从美观上讲，的确，需要用空白的间隔会更好看。那么怎么处理这个空白间隔呢？想必大家都觉得这个有什么好讲的，搞个margin或者padding不就好了嘛，emmm...我一开始也是这么想的，但是准备写代码的时候，就会觉得好麻烦（- _ - 我懒）：

为第一个div设置个margin-left？那区别对待吧，加个类名，然后设置css。
两个div的宽度和margin值计算好分配好空间占比
那么小屏幕换行的时候，就会多了个margin-left了，那媒体查询处理掉吧

思路很清晰，实现起来也是非常简单的。但是，我后来还是放弃了，
第一我觉得，少点类名，代码更漂亮；
第二，我觉得起名字好烦啊，用伪类？可以啊，但是也要处理好能否真的定位好这个，撇去本身项目的代码的一个整体环境，其实也是很简单的，但是当置于一个复杂的代码环境里，各种命名错综复杂的情况下，少用伪类还是较为保险；
第三，我不想计算；
第四，关键的关键是，我觉得存在更好的办法。

更好的办法（还是要类名，但是项目里我是统一了两个类名）

/** 这两个类名估计大家都很熟悉，但是我项目没有引用boostrap，这是我自己定义的全局类名 **/
.pull-left {
    float: left!important;
}
.pull-right {
    float: right!important;
}

回到这个图里，我为第一个div设置了pull-left类名，第二个div设置了pull-right类名。
但是他们的宽度不再是width: 50%了，改成更小的值，以便留出需要的空白空间。（当然，有些人可能一开始就想到用这个布局了，这里只是在引导一个思考方式，最终形成一个好的思路而已）

图形的特殊情况

开发者们都深有体会，要实现一个ui图上的页面不难，难就难在，存在多种情况，多种未知因素，进而导致的个别特殊情况或极端情况。如果说，开发时间为100%，那么还原ui图的情况（正常的情况），占据了70%时间，30%就花在处理这些极端情况上了。心里面就觉得很愤懑不平，明明这些特殊情况和极端情况出现概率那么小，缺花费了那么多时间去搞，甚至把代码都搞得更复杂，维护也不好。但是，这就是现实，没办法了，我们能做的就是，在开始coding前，尽量全面考虑，从中制定方案，避免开发到一半发现写不下去更换方案这就尴尬了。

废话不多说，这里会有什么特殊情况呢？以饼图为例子。

情景一

说一下大致背景需求，这里的饼图有多少组数据不是固定的，什么意思，图上不是有六组数据嘛（红书发布、搜狗搜索...），就是图上六中颜色的数据嘛。这些数据个数，都是未知的，可能很多可能很少。

了解基础背景后，大家有什么想法。

由于这些数据个数都是未知的，因此我们要考虑好两个极端的情况，非常少数据的情况（也就是1组数据），一个是很多数据（无穷）。 会对图形有什么影响？变现在？

数据的多少，会表现在图例上，要考虑哪些问题呢（渐进式思考）？

不论图例多少，整体图例的位置都要垂直居中于饼图，因此legend的top值，不能是其他数值，只能是'middle'，那么数据很多的时候，是否会自动继续往下堆叠，仍然保持垂直居中呢？
包含echart的图的container，一定要设置宽度和高度才能呈现出图，因此，不能实现高度随着图例的变多而变高，因此光设置个middle仍不足。一般情况下，既然设置了高度了，如果图例数目往下排列的时候到达高度的极限，会自动新增第二列。但是在这里，由于一行存在两个div，而且宽也设定了，明显让其自由这么发展下去，只会有一部分图例被遮挡住了。
很遗憾，面对这种问题，虽然ui图上没有考虑到多图例的情况，产品经理也可能没考虑到，那么或许我们需要自己决定改造一下了（最好咨询一下产品吧），反正就是，我们要有这个极端意识。解决办法就是，利用echarts提供的图例分页功能了。类似这种

情景二

上面也说了，有多少组数据都是未知，那么这些数据的名称（小红书发布这些...）也是未知的，自然这些名称长度也是未知的。那么问题就来了，如果名字很长怎么办？
思路：

echarts的图例很长的时候，不会自动换行的，当然选择了canvas生成的图，更加不可能通过样式改变了。而我们这里，如果名称很长了，会超出到屏幕外面，不好！
ui图也没告诉你这种情况下该怎么办？但是，我们一定要有这个意识（重复了很多遍了，我自己都嫌自己），能怎么办？截断呗。至于截断的方式，可以用字符串的阶段，也可以用echart自带的一个方法截断（自己去查，印象才更深）

是不是截断了就没事了？错，图例的水平位置就要考虑好了，如果还是以ui图那些图例情况来考虑水平位置的放置的话，可能真遇到需要截断的情况下，水平位置放得不好的话，就会出现就算你截断了，但是还是显示不出来，直接被父层的元素给砍掉了内容。
因此，要结合屏幕的情况，考虑好截断多少，然后以这种截断后的情况来调整图例的水平位置，这样才能避免上述问题。既然截断了，用户也就不知道真正的名字了，那么我们自然也要需要为截断的图例提供tooltip，用echart的图例tooltip功能就好了

三）既然数据的名称会有很长的情况，那么自然而然，对应的tooltip上的名称，也会很长。这里的tooltip有两种，一种是悬浮在饼图上的tooltip，一个是悬浮在图例上的tooltip

不论哪种tooltip，存在的问题性质上是一样的。

如图，如果名称像红框那么长，那么tooltip也会这么长，如果不幸tooltip的层级不够高，还有可能被别的元素遮挡住了。
对于图例的tooltip，名称一定要展示完全的，不然都省略了，这个tooltip就没啥意义了。但是也不能让它那么长，咋办？那就让他自动换行呗。至于自动换行的方法，我不知道能不能设置这个tooltip的宽度，如果可以的话，可以设置宽度，然里面的文字自动换行就好了。如果不行，那就截断字符串，用'\n'连接再展示出来就可以了（我是用这种）。
对于悬浮在饼图上展示的tooltip，同样用上述的换行方式也可以，也可以用截断的方式，反正都有图例说明了，但是还是换行好点吧，具体问自己的产品经理吧。
那么问题就来了，到多宽才进行换行/截断呢？先看个失败的例子：

5. 截断的宽度把握不好，就会还是存在被强制遮盖的情况。因此，具体要多宽，自己要综合页面上的各种情况来好好斟酌了，多测试。

最后

大概要想说的就这么点了，其实真要处理起来，细节的东西还是很多的，不过我也不多说了。希望大家以后在拿到ui图拿到需求后，不要过于着急马上进行开发，还是先理解好需求，考虑好各种情况下，在进行编码。此篇文章或许对你思考起到那么丁点作用，这样我也感到开心。祝各位开发者越来越厉害~~~