重构b2b页面为配置化、低代码化

背景

用过数据分析平台的大概都知道，会有多个分析模型，大概都会有事件分析、留存分析、间隔分析、分布分析等等。

这些个分析模型，用起来也都感觉差不多，搭建要分析的数据条件，展示指定的图表。

数据条件呢，大概也就是，要分析的事件，条件筛选，数据按什么分组、分析的主体、时间段等等。

展示的图表又分为折线图、直方图、桑基图等等，以及按照不同的模型处理成不同的表格。

从上面也可以看出来，分析模型呐，基本上就是数据分析平台这类产品的卖点。而这部分的业务逻辑，有些都是五年前定下来的，可谓是一座x山。

最近又接了两个大活，要新上两个新的模型分析，样子长得跟其他的也都差不多，只是额外多几种新的条件选择器，图表也长得不太一样。

这可把我难住了。

难的不是做新的需求，难的是要适配、兼容模型通用逻辑。

哎，这我就脑子一热，干脆把分析模型都给他重构了。你们不是都长得差不多吗？那就干脆搞起配置化，后面也可以继续搞成低代码。

说干就干，具体怎么实现，请往下看。

理清逻辑

配置化，那就要有一定的配置规范。在前期，可以通过类型来约束配置。

区分不同配置项的字段，可以定义为 【type】。 比如，输入框的type为input，按钮的type为Button，按钮组的type为 ButtonList。

作为数据条件，在接口参数中也会有各自的key，那就可以用key来作为【key】。

大部分配置项都会有自己的【title】，少部分没有，但是报错提醒也让他们需要一个【errorTitle】。

配置项在页面的哪个位置呢，这也需要一个属性【location】

作为输入向的数据条件配置项，也要有是否必填的属性【required】，还有一些配置项的是否展示是依赖其他配置项的，就可以用【enabled】属性。

还有针对配置项的各种更多的配置，比如说 按钮的大小 这种，就可以封装在【props】里面。

配置项类型的属性差不多就这些。当然还有一些其他的，后面再讲到。

配置接口文件大概就如下

type TPageLocate =
  | 'search'
  | 'header'
  | 'toolbar'
  | 'chart';
 
type TConfigType =
  | 'input'
  | 'switch'
  | 'select'
  | 'header';
 
type TConfigBasic = {
  type: TConfigType;
  key?: string;
  title?: string;
  errorTitle?: string; // 隐藏的title，用于报错提示
  props?: any;
  enabled?: string;
  keyDeps?: TTgaConfigKeyDep[];
  pageLocate?: TTgaPageLocate;
  required?: boolean;
};

写组件

已经理清了配置项的内容，下面就开始完成一个配置化的组件。

下面是一个ConfiguableInput的例子

type TInputConfigProps = {
  bordered?: boolean;
}
 
type TConfigComponentProps = {
  config: TConfigBasic,
  
}
const ConfiguableInput:FC<TConfigComponentProps> = ({
 
}) => {
 
}