关于可视化技术选型的思考

缘由

最近给海外组做图解财报的3D组件，陆陆续续耗费了我不少时间，但是最终回头来看，这个需求实际上可能只需要1天就能搞出来。究其原因，在于我的技术方案选型上，误入歧途了。

这其实算是一个特别偏业务的定制需求，里面的3D内容并不通用，难以在其他的场景下复用。然而我用做通用组件的思维去写代码，这样就额外的做了很多过度设计，代码量也暴增。当然这也不是一点好处没有，至少让我对于3D组件开发有了更深的理解，且这次的框架也可以用于后续通用组件的开发，但是回到需求本身，这绝对是一次错误的技术选型。

因此我觉得有必要总结一下可视化需求的技术选型思路，避免今后重蹈覆辙。

不同类型的可视化库的定位

首先我们要理解清楚，像Three.js、ZRender、D3.js这种库，其定位是脱离业务的偏底层的渲染库，如果有个性化的业务开发需求，我们应该直接基于这些库来开发，这样开发效率是极高的，因为这样可以保有足够大的自由度，正好能解决业务需求个性化的特点。

而像ECharts、Vis.js等，是基于底层渲染库之上的、针对特定领域的组件，提供了快速解决常规需求的能力，但是同时降低了自由度。因此这些工具适合对于UI交互没有很高要求的场景，比如内部工具平台等。和业务特性绑定的需求，就不适合用这些工具了，因为你很可能被一些小的需求点给卡住，然后你发现必须得了解整个库的源码才有可能解决，甚至有时候你发现需求和这些库的设计理念是冲突的，那就得去动源码了，成本非常之高。

不同的组件类型

通用组件

比如折柱饼，这种组件，我们应该通过范式去约束，这是很适合投入大量精力细细打磨的，然后一劳永逸。

技术选型上，可以找一个成熟的组件库，深入剖析其原理后，站在巨人的肩膀上，根据设计标准进行局部扩展。

这种组件因为复用性强，用到的场景多，且基本上已经形成业界标准的交互和UI了，不建议我们自己全部重头搞，否则后期维护成本会很高。

业务组件

比如这次的图解财报中的3D柱状图，就算是一个业务组件，因为和具体的业务(财报)绑定了，其交互、视觉效果都是为了这个业务设计的，且对于上线时间有要求，没有充足的时间给我们去慢慢打磨程序。

这种组件复用度不高，只能做到同类业务复用。因此可以稍微放低对于程序设计的要求，开放的配置项也不用太多，尽量做到高内聚。

这类需求适合选一个兼容性好的渲染库，在此基础上我们做一个自己的业务组件开发框架，然后基于该框架开发业务组件。

业务开发

完全不具备复用性的纯业务需求，这种就适合以常规的流水账形式开发，追求快速出活儿，不用考虑复用性。

这种需求同样可以由我们自己搞一个基础的程序框架，把程序结构、通用函数方法封装好，然后基于该程序框架快速做业务。

可以参考react-three-fiber的模式。

不要局限于某项技术

需要注意：不一定非得用3D技术才能实现3D效果，还有很多其他的方案：

无需数据驱动：序列帧、Lottie、svga、视频、CSS伪3D……

需要数据驱动：序列帧、CSS伪3D……

技术是为了解决问题的，不要死守一个技术不放。