记EditableProTable高级表格组件之坑20220122

背景：

今天是2022年1月22日星期六，此刻我拖着同事坐在办公室里加班，需求页面中某一表格因产品业务逻辑不清晰，反复更改交互，写到一半发现业务流程走不下去，原稿的UED也被改的面目全非，导致表格所依赖的第三方组件EditableProTable高级组件，彻底 被 玩 坏 了

产品要求1月24日上线，而此刻清单里还躺着10几个组件的bug

分析：

痛定思痛，还是重新梳理一下这边的业务逻辑吧

这是最初的UED，2021.12.25-2022.1.22历经修复了60几个业务变更的bug之后，最后确认的最终一版的交互逻辑是这样的

1、根据操作场景：新增、变更、编辑、补录、详情五种场景分别对账户信息的表格列表新增或引入，针对新增或引入的表格进行编辑、删除、保存、取消动作

2、其中组件1一经选中，自动回填其他组件值，请求2和3的下拉列表，分别自动带出2和3，如无值手动选择，3带出后自动查询4、5列表且要求自动带出4、5、6、7字段 其中1和2、3一对多，3、4、5、6、7一对一，清空逻辑同步自动选中的逻辑

3、在编辑表格前查询接口判断表头的每个字段是否必填月是否允许修改(校验规则)

目前业务上流程问题有

1、当某一个字段查询到校验规则是必填且不允许修改，而自动回填查询到数据又是null时，则提交保存时接口就会报错校验不过

2、当组件1code一经选中，查询出的组件2列表可能为空，且自动回填也为空，此时用户无列表可选

所依赖的组件是

遇到的坑：

1、所依赖的antd的包太大，框架中本身也引入了YH-antd的一套组件，source-map里有两套antd的包，导致打包的内存过大，部署失败，后来通过扩大内存和在按需加载引入包解决

2、因为可编辑的单元格需要互相联动，ProForm和EditableProTable同时使用renderForItem包含自定义组件时<ProForm.Item name=“xxx”></ProForm.Item>会导致一些组件值无法赋值，引发无法实现联动的交互，组件本身的缺陷

3、当引入外部列表时，表头会有editAble函数来区分renderForItem节点还是render()节点，这是表格自身的editAble，由于需求中也需要对组件edit状态进行控制，会干扰DOM节点的渲染

4、使用自定义组件renderForItem时，要使用ProForm包裹，YHForm、和Form都没用

5、api和文档都比较简陋，案例比较少

最终解决方案：

鉴于以上的坑，最终换掉EditableProTable组件，使用YHTable手写一个可编辑表格的组件，方便修改内部交互