数据驱动在转转客服工单系统中的应用

客服工单系统是客服解决用户实际问题、处理日常工作最常用的系统。为有效辅助客服的工作，系统需要及时提供用户、商品和订单等信息。同时，客服工单的创建、流转和处理，也需要各种类型表单的操作。所以基础信息的展示和交互、表单的展示和操作，对于客服工单系统至关重要。本文就为大家介绍，在转转客服工单系统中，我们是如何通过数据驱动的方式解决这类问题的。

基础信息

展示形式

这里以工单详情为例，工单详情以模块的方式，提供包括基础信息、用户信息、订单信息等重要的数据，如下图：

每一个模块都是由大量不同的类型信息平铺展示，如下：

这些信息数据量和类型繁多，数据字段跟公司的业务有关，数据类型涵盖从最简单的文本展示、链接跳转，到图片预览、弹窗交互等，这些不可能由前端单独一一去做处理。所以我们通过归类和抽象，将数据格式进行统一化、对共性组件进行抽离，交由不同的组件处理。在介绍基本使用之前，先看下整体的结构设计。

结构设计

四个层次

工单详情的每一个大模块都可以分为四个层次，分别为：数据共享层、业务层、抽象层、数据展示层。

每一个业务层都是一个可折叠的面板，未展开前都只展示简略信息。其数据均由数据共享层提供，展开后可通过请求共享的 url，获取详细数据。

这里控制请求逻辑的就是抽象层。 其中包括了一个展开后自动请求的 hook---useAbstract，以及一个根据 useAbstract 返回值控制展示的 Abstract 组件，获取到的数据最终传给数据展示层--DetailInfoArea。

//  useAbstract
const [infoDataList, isEmptyInfo, loading] = useAbstract({ isShow, initShowData })
// 这里infoDataList为返回数据，isEmptyInfo用于控制展示，loading是加载状态

// Abstract
<Abstract infoDataList={infoDataList} isEmptyInfo={isEmptyInfo} isLoading={loading}></Abstract>

// DetailInfoArea
{!isEmptyInfo
    ? infoDataList
      .filter((item) => Array.isArray(item.data) && item.data.length)
      .map((infoItem, index) => {
        return (
          <Card key={index}>
            <DetailInfoArea
              orderId={orderId}
              bussinessType={bussinessType}
              data={infoItem.data}
            />
          </Card>
        )
      })
: null}

最终通过一个 type 和组件的映射匹配出相应的组件。

import PopInfo from '../PopUp/PopInfo'
import LinkAirPlane from '../FormComponent/LinkAirPlane'
import Text from '../FormComponent/Text'
import countDown from '../FormComponent/CountDown'
…… // 其他组件

export default {
  // Pop类组件
  PopInfo,
  PopDrawer,
  // link类组件
  LinkAirPlane,
  // 其他数据展示组件
  Text,
  countDown,
  ……
}

三类组件

通用数据展示组件分为三大类：pop 类 、 link 类、其他类型组件。

1. Pop 类组件：用于点击后弹窗/抽屉展示数据或操作--常用做其他数据展示的容器
2. Link 类组件：由于点击后跳转
3. 其他类型组件：基础展示 text、table 数据、图片/视频展示...

具体组件类型、名称和作用如下：

数据结构

以下为每一个数据展示项的基本数据结构

[
     {
          "type": "", // 用于匹配系统中内置的组件
          "label": "", // 标识数据项的标题
          "value": "", // 标识数据项的值
          "noAuth": "", // 没有该项查看权限的标识
          "extInfo": { // 额外的信息，可以放入href、formType字段从而达到嵌套组件的形式
              ....
          }
      }...
 ]

基本使用

案例 1：展示用户的基础信息，其中包括用户名、注册时间、手机号、头像以及一个测试流水表格

{
  "respData":[ // 对应最外层模块内容
      {
          "label":"基础信息", // 模块的名称
          "data":[ // 模块中信息项：以label--value的形似展示
                {
                    "label":"用户名",
                    "value":"转转第一"
                    "noAuth":false
                },
                {
                    "label":"注册时间",
                    "value":"2022-02-21",
                    "noAuth":false
                },
                {
                  "label":"手机号",
                  "value":"182****328",
                  "type":"ClickReplace",
                  "extInfo":{ // extInfo用于放一些组件需要的特殊参数
                      "params":{
                          "uid":"12345678910233445"
                      },
                      "url":"url"
                  },
                  "noAuth":false
                },
                {
                    "label":"",
                    "value":"https://abababab.jpeg",
                    "type":"ImgHoverPop",
                    "extInfo":{
                        "popWidth":"200px"
                    },
                    "noAuth":false
                },
                {
                "label":"",
                "value":"测试流水",
                "type":"SimpleTable",
                "extInfo":{
                    "data":[
                       // 表格数据
                    ],
                    "columns":[
                        // 表格列配置
                    ]
                },
                "noAuth":false
            }
          ],
          "noAuth":false
      }
  ],
  "respCode":"0"
}

展示内容如图所示

本例前两个字段使用的默认的渲染类型，只展示单一信息

手机号和头像展示则匹配了内部的通用组件：

• 手机号采用了脱敏的方式，只有在点击之后才会加载全手机号，属于单一数据展示类组件

• 第三项使用了缩略图的展示形式，点击后会对图片进行预览，属于单一数据展示类组件

• 最后的流水表格使用内部的SimpleTable组件展示

嵌套使用

案例 2：我们在基础信息部分需要展示一个流水，以弹窗的方式实现。这里就要通过嵌套的方式进行处理。

这里涉及到的弹窗组件就是上文所说的 Pop 类组件，如下所示：

这里使用的是 PopInfo，extInfo 中增加 url 表示弹窗的内容通过 getUserFlowList 获取，因此点击“测试流水详情”后会请求该接口。

{
  "label":"测试流水",
  "value":"测试流水详情",
  "type":"PopInfo",
  "extInfo":{
  "url":"getUserFlowList"
  },
  "noAuth":false
}

获取接口后，其返回数据既返回了数据 data，也返回了表格的列配置。

{
    "respData":{
        "dataGroup":[
            {
                "type":"SimpleTable",
                "extInfo":{
                    "data":[
                        // ......
                    ],
                    "columns":[
                        // ......
                    ]
                }
            }
        ]
    },
    "respCode":"0"
  }

此处弹窗中的内容为流水信息，使用表格来展示，type 为案例 1 所用的 SimpleTable 组件。

对比一下案例 1 中直接使用 SimpleTable，此处嵌套使用时，只需通过数据获取接口来衔接弹窗和内部数据的，其返回数据的结构都是保持一致的，这也是此设计可以嵌套使用的根本原因。

接下来将焦点转移到工单系统中的表单信息。表单在工单系统的地位用“灵魂”形容可能也不为过，因为客服解决用户问题的过程，涉及到记录问题内容、问题分类、沟通细节、处理方式、工单流转等，这些操作都依赖表单的能力。所以一套强大的表单处理系统对实现工单系统流转起到关键作用，下面介绍由数据驱动的 FormRender 在工单系统中的应用。

表单信息

在工单系统，我们使用 FormRender 处理表单。为什么是 FormRender，而不是普通的 Form？

1、同基础信息类似，表单中的字段非常多，包含输入框、单选框、多选框、下拉框、日期选择、时间选择、级联等。

2、字段本身有很多的配置项，如校验规则、默认值、联动信息等，所以需要一种强约束的数据格式保证表单字段的正常渲染和交互。

3、针对不同的用户问题，客服创建的工单需要由不同的字段组合来承载信息，如果没有统一的表单管理，维护效率不容乐观。

FormRender（后面简称 FR） 是一个通过 JSON Schema 生成标准 Form 的渲染引擎，也是一站式表单方案，拥有比较强大的功能，可以满足复杂的表单需求。接下来看看 FR 如何运用在工单系统中。

FormRender 的基本使用

比较下面的代码

// input第一种写法
<Form>
    <Form.Item
    required
    label={'这是输入框'}
        <Input placeholder={'请输入~'}  className={style['my-input']}/>
    </Form.Item>
</Form>


// formRender的写法
const form = useForm()
const renderSchema = {
    displayType: 'row',
    labelWidth: 130,
    type: 'object',
    properties: {
        content: {
            title: '这是输入框',
            placeholder: '请输入~',
            type: 'string',
            required: true,
            "props": {
                className: style['my-input'],
            }
        }
    }
}
<FormRender schema={renderSchema} form={form} />

最终的效果如下：

我们可以看到，其实 FR 是借助schema对表单做了相应的配置化。

FR 是如何通过 schema 渲染指定的组件呢？FR 属性 type，描述组件的值的数据类型，属性 format，用来描述输入框的格式，它与属性 type 一起可以判断使用哪个组件来渲染，以及校验表单数据。

内置组件与 scheme 的默认匹配规则为：

export const mapping = {
    default: 'input',
    string: 'input',
    array: 'list',
    boolean: 'checkbox',
    integer: 'number',
    number: 'number',
    object: 'map',
    html: 'html',
    'string:upload': 'upload',
    'string:url': 'url',
    'string:dateTime': 'date',
    'string:date': 'date',
    'string:time': 'time',
    'string:textarea': 'textarea',
    'string:color': 'color',
    'string:image': 'imageInput',
    'range:time': 'timeRange',
    'range:date': 'dateRange',
    'range:dateTime': 'dateRange',
    '?enum': 'radio','?enum_long': 'select',
    'array?enum': 'checkboxes',
    'array?enum_long': 'multiSelect',
    '*?readOnly': 'html',
};

除了有以上内置组件外，FR 还支持自定义组件，通过 widget 属性（将在下一节中介绍）注入。

另外，FR 通过 rules 属性来配置对表单的校验规则，通过 props 属性透传给组件，用来扩展字段，值得强调的是 FR 支持所有 antd 组件库支持的展示。

自定义组件

工单系统目前支持的表单类型包括：文本框、文本域、单选、多选、下拉、级联、日期选择、时间选择，大部分都可由 FR 的内置组件支持，但有些特殊的需求，FR 不能很好的支持，级联组件就是其中一个。

如何在 FR 中写一个自定义组件？

// 引入自定义组件
import CascaderSingle from './CascaderSingle'
// 定义schema数据
const renderSchema = {
    displayType: 'row',
    labelWidth: 130,
    type: 'object',
    properties: {
        cascader: {
            title: '城市',
            type: 'string',
            widget: 'CascaderSingle' // widget指定自定义组件名称
            "props": { // 定义渲染数据
                options: [{
                    id: '1001',
                    name: '北京',
                    children: [{
                        id: '10011',
                        name: '海淀',
                        children: [{
                            id: '100111',
                            name: '好地方'
                            }]
                        },
                        {
                            id: '10011',
                            name: '朝阳'
                        }]
                    }]
                }
            }
        }
    }
// 将自定义组件，通过widgets通知FR渲染
<FormRender widgets={{ CascaderSingle }} schema={renderSchema} form={form} />

渲染效果如下：

总结以下几点：

1. 自定义的组件，需要支持 value/onChange 这两个 props，用于双向绑定；
2. 通过 widgets 给 FR 注册自定义的组件；
3. 设置对应的 schema 数据，包括 widget 属性和自定义组件接受的 props（上述例子中的 options）

一般自定义组件，通常是解决特定的场景需求，如特殊 UI、特定的组件、异步加载数据的组件等。在下一节会介绍异步加载数据的场景。

生命周期

对于 FR 来说，生命周期是指渲染和提交数据的时机，根据官网介绍，包括 onMount、beforeFinish 和 onFinish。

• onMount 用于加载初始数据；
• beforeFinish 用于提交表单前的服务器校验；
• onFinish 是获取表单数据和校验信息。
• onMount 需要特别强调的是，它是指表单首次加载时执行，而且 schema 数据不能为空（undefined、null 和{}均表示空数据）。如果初始的 schema 数据是由服务器异步加载，那么 onMount 一般无法满足需求，官方则推荐使用 react 的 componentDidMount 或类似的 hooks 来加载。

在工单系统中，绝大多数的表单初始数据都是由接口获取，所以一般很少用到 onMount。但有一个例外，其中有一个级联表单，虽然初始数据是非空 schema 数据（一般是简单的配置项），但真正的 options 数据是由单独的接口异步获取，这时 onMount 就派上用场了，因为 onMount 还能用来通过异步获取数据的方式进一步补充 schema。

const onMount = () => {
    //通过接口异步获取数据
    apiQueryAllRootCause().then((res) => {
      const _data = res?.dataList?.map((item) => {
        return { ...item, name: item.causeName, key: item.id, isLeaf: item.isEnd == 1 }
      })
      //获取需要补充schema的字段的路径
      const schemaPath = getSchemaPath(infos?.formData?.find((it) => it.fieldType == type))
      //补充schema数据
      form.setSchemaByPath(schemaPath, {
        props: {
          options: handleGetFaqData(_data)
        },
        enumArea: _data
      })
    })
  }
  <FormRender
    widgets={widgets}
    schema={renderSchema}
    form={form}
    onMount={onMount}
  />

这里用到了 FR 的 setSchemaByPath 方法，它的目的就是对指定路径修改 schema。由于 schema 是有一定结构格式的数据，为了方便快速定位具体某个元素，用 path 来表示该元素相对表单数据的位置。我们看官网给的例子：

const formData = { x: [{ y: { z: 1 } }] };

那么 z 元素的 path 是 x[0].y.z。所以在工单系统复杂的表单中，要对指定的表单元素修改 schema，通过 path 设置是一个非常高效的选择。（更多关于 path 的内容，详见：如何正确书写 path  https://xrender.fun/form-render/demos/index3）

表单的其他设计

在工单系统，系统管理人员会配置大量的字段，由于历史原因，保存字段的时候并非标准 schema 数据，所以当通过字段创建表单时，需要进行一次格式转换，如下图。左图为转换之前格式，右图为转换后的 schema 格式。

在右图中我们注意到，字段元素【字段 2】外层又包裹了一层 schema 格式数据，并且用字母 a 表示元素数据，这是为了美化排版，节省页面空间，产品设计中增加了双列展示的效果，系统通过字母组合来表示具体的某一行。如下图：

在组件自定义方面，增加上传功能、拖拽功能、异步请求的级联组件、联动组件等，可以满足业务多种场景需求。

总结

数据驱动的好处，在于前后端可以通过清晰的数据格式明确页面的呈现和交互效果；另外，在修改数据时，可以只修改接口返回，而前端无需上线。

数据驱动在客服工单系统中的应用还有很多，比如表格视图、流程渲染等，这些应用都能大幅提高开发效率和维护性。

在追求低代码的大潮流下，客服工单系统虽然非常复杂，但我们吸取低代码的设计思想去简化系统的复杂度。