SpreadJS 的三大应用场景

3.1 三大应用场景简介

根据数据的存储方式和数据流向即可判断应用场景的分类,SpreadJS 的各个场景并非独立,也可能同时出现。

  • 表格文档协同编辑:数据直接通过Excel文档或者JSON等其他文件方式存储在磁盘或者数据库。
  • 数据填报:用户通过输入、选择、导入等方式录入数据并存储。
  • 类 Excel 报表设计:数据从存储结构中通过表格、公式、图表等方式进行展示,或导出 Excel 和 PDF 时。

 

3.2 场景一:表格文档协同编辑

场景特点

  • 多人协作、实时编辑,要求较高的数据传输效率
  • 数据同步、多级上报,提供必要的流程管控
  • 无需 IT、研发部门介入,业务部门可自行完成配置,快速响应需求

技术难点

1. 多人协作和数据处理效率低
  • 研发多人协同编辑模块需要较高的成本
  • 数据传输效率和数据同步性难以保证
  • 不支持多人同时编辑,缺乏必要的流程管控
  • 协同编辑时,无法留存记录和历史版本
  • 不能有效解决实时通信和数据冲突等问题
2. 难以二次扩展、系统易用性差
  • 组件功能缺乏,需要对源码大量修改
  • 对数值操作的颗粒度不够,用户使用体验差
  • 产品功能需要依赖第三方组件
  • 内置 API 接口数量少,可扩展性不足
  • 需求变化响应不及时,需要研发部门介入
3. 与原系统、框架的兼容性不够
  • 非前端架构,存在依赖项,需要预装环境
  • 不兼容 Excel 数据源、不支持 Excel 导入导出
  • 难以嵌入各类应用及技术框架中
  • 无法与后端技术框架(如 Java、.NET)相结合
  • 不支持跨平台开发和多终端设备

该场景的典型案例

 

3.3 场景二:数据填报

场景特点

  • 表单布局样式复杂,存在大量需要自由合并的区域,需要提供类似纸质表单的样式
  • 全方位数据校验,有大量字段需要实现数据验证、逻辑校验等功能
  • 需要支持填写、列表项和预览打印。同一表单,需要多页面支持,前期开发、后期维护成本高
  • 需求更新频繁。项目发布后,经常需要对表单布局、字段、验证等功能进行修改
  • 数据绑定&输入类型丰富,需要支持基础数据绑定,提供多种输入类型,如:文本框、下拉菜单、区域模板、按钮、形状、树状图、迷你图、批注等

技术难点

1. 填报系统的使用门槛高
  • 业务人员已习惯 Excel 的操作模式
  • 不支持在线填报数据,缺乏必要的流程管控
  • 不兼容 Excel 数据格式、公式和图表
  • 不支持在线导入、导出 Excel 文档
  • 系统使用门槛高,需要专门培训
2. 组件功能与二次扩展能力不足
  • 组件样式单一,无法设计复杂模板布局
  • 不提供数据绑定和数据校验功能
  • 数据填报组件功能缺乏,无法二次扩展
  • 不可嵌入各类系统及技术框架中
  • 无法跨平台在线使用,需要预装环境
3. 数据迁移成本与后期维护难度大
  • 新系统的填报模板不兼容原始数据结构
  • 填报功能升级需要开发人员介入
  • 业务人员无法自行设计填报表单并发布
  • 性能难以保证,无法实现大数据量填报
  • 组件定制化能力不足,无法实现个性化填报控制

该场景的典型案例

 

3.4 场景三:类 Excel 报表设计

场景特点

  • 生成的报表需要导出 Excel,满足各类财务、税务、审计报表的系统内设计、编辑、导出和打印
  • 需要重用大量原始 Excel 的报表模板
  • 设计工具需要向最终用户(财务、行政等)提供类 Excel 的使用体验,降低培训成本和使用门槛
  • 作为展示和使用数据的过程,该场景要求报表设计平台的易用性、产出的报告可导出、可编辑,同时可以利用已有的报表模板

技术难点

1. 报表设计器的易用性差
  • 不符合 Excel 的使用习惯,学习门槛高
  • 不具备拖拉拽和“所见即所得”的设计模式
  • 无法跨平台在线使用,需要预装环境
  • 可视化组件缺失,无法二次扩展和个性化定制
  • 难以嵌入各类系统及技术框架中
2. 报表数据的导出与分析能力不足
  • 数据无法在线导出、在线解析
  • 不支持 PDF、CSV、Excel 等常见文档格式
  • 无法保留公式、图表等元数据信息
  • 导出模板丢失表内各元素联动状态
  • 报表结果不可编辑,计算性能成为瓶颈
3. 无法复用原始 Excel 模板
  • 不兼容原始 Excel 报表样式及数据结构
  • 无法通过 Excel 来定义单元格的名称域
  • 支持 Excel 的公式、图表、单元格状态数量少
  • 无法绑定数据模版并动态填充数据
  • 无法动态构造表单模版

该场景的典型案例