智能短视频-组件设计
名词概念
组件库
比如我们的D3Charts，就是一个组件库；而其他零散的组件，比如动态折线图、柱状图这种，并不算是组件库。
后面我们应该将组件都集中起来，以组件库的形式解决我们的组件需求，这样可以保持规范性，便于后续的使用和维护。而且通过组件库的方式降低组件数量，也可以让我们有更多的精力放在设计上面，保证组件的质量。
基础组件
基础组件是基于组件库进行配置的、具备比较高的通用性的组件，且一定是符合我们的设计规范的。
这种组件一般表现力比较普通，比如柱状图就只有基本的坐标轴、柱子等等。
业务组件
业务组件是包含了特定业务需求逻辑的组件，是为了解决业务个性化需求而生的。
比如下面这个图中的柱状图，为了突出最新一期数据，最后一个柱子需要标注为其他颜色：
业务组件的复用性比基础组件差很多，但是具有较强的针对性的表现力。
可以预见，我们的平台，今后应该有大量的业务组件，用户最常用的也是业务组件。因此我们需要考虑如何提升业务组件的生成效率，这可能需要将DataV组件配置平台结合进来。
设计思路
简化程序设计的复杂度
我们目前的程序做了很多的潜规则逻辑，以适应各种不同的需求场景。原因在于我们没有进行模块划分，每个人/每个模块不清楚自己该做什么/不该做什么，导致程序耦合度非常高。
举几个例子：
- 数据处理的逻辑没有明确是前端做还是后端做，导致不同的模板，返回的数据结构不一致
- 没有明确哪些内容该渲染器面做，哪些该组件内部消化，导致渲染器做了很多和组件高度耦合的逻辑
解决这些问题的关键，个人感觉就在于标准化、业务组件和数据池。下面会详细描述。
标准化
我们做的是一个平台，而平台一定是通过标准化的方式，提供一些标准的素材(积木)，帮助用户搭建内容。因为每个人的想法都是不一样的，我们是无法实现用户所有的个性化需求的，如果不做标准化，我们就会疲于奔命的去做定制开发，这样会限制平台的能力。
这里的标准，分为这几部分：
- 前后端数据对接的标准
- 组件接入标准
- 组件数据格式标准
- 组件配置项标准
通过业务组件解决个性化需求
不要想着用一个组件解决用户的所有需求，这是不现实的。比如你想用一个柱状图解决用户所有的柱状图需求，那么你势必会将这个柱状图组件做得非常复杂，暴露的配置项也会越来越多，这样导致的结果就是你根本无法满足用户需求(因为用户需求是会不断变更的)，且这个组件会非常难以维护，而且因为暴露的配置太多，对于用户来说，使用成本极高，最终导致用户不可用。
所以我们的思路一定是：通过足够多的业务组件来解决个性化需求，每个业务组件的职责单一明确，开放的配置项很少。
将formatter在组件内部消化掉
formatter是一个噩梦，给组件的维护带来很大的弊端，因此我们需要将formatter在组件内部消化掉，将其作为组件的内置逻辑，决不能暴露给使用者。
数据池&后端接口数据的标准化
1.0模板转2.0模板，前端开发的很多时间耗费在了解析后端数据上，究其原因，在于当初制定的前后端数据对接协议不够统一，且不够简单。
因此后面需要对这一块进行优化，即针对定制化模板，后端将数据处理逻辑消化掉，提供一个数据池，让前端可以直接通过数据id获取最终的作图数据。
举个例子，比如后面我们要新做一个定制化的财报模板，会用柱状图展示某个公司的净利润数据，那么后端需要将净利润数据请求回来，并处理成柱状图组件所需的数据格式，然后通过一个数据键名，比如profit，直接返回给前端；前端配置页面模板的时候，只需要将柱状图和这个profit键名做一个绑定即可。
组件制作流程
平台稳定后，我们会有大量的组件需求，靠人一个个手动开发是不现实的，这样我们开发人员就会成为平台发展的瓶颈。因此我们需要通过工具来快速生产业务组件。
鉴于我们有DataV平台，可以让开发人员基于现有Demo快速配置组件，因此可以将这个平台作为组件生产工具链的一个环节，最终的组件生产流程如下：
graph LR
a(DataV平台选择一个类似的基础组件) --> b(配置formatter) --> c(配置需要暴露的配置项) --> d(导入组件数据库) --> e(短视频平台应用)
案例分析
有颜色要求的排名柱状图
数据如何处理？
我们需要增强数据处理功能。
graph LR
a(数据提取-NLP240/行情等) --> b(数据标准化) --> c(对接标准组件)
附录
Markdown画流程图：