TDesign Next 糟糕的地方

可编辑表格功能不足

现有的可编辑表格组件在设计上，将可编辑组件的配置局限于列级别。这种设计虽然简单，但在处理复杂业务逻辑时，暴露出极大的局限性。

• 僵硬的组件绑定： 它通常只提供一个固定的 edit.component 属性和简单的 props 传递机制。这意味着，无论哪一行数据，只要是该列，就必须显示相同的表单组件。
• 缺乏行内容感知： 无法根据不同行的数据内容（row）来动态地切换或自定义表单组件的类型、配置或样式。

对比： 业界优秀组件库（例如 Ant Design）提供了如 renderFormItem 这样的高级自定义功能。通过回调函数，并传入当前的 row 数据，开发者可以轻松实现“行表单组件高度自定义”，使表单输入与行数据紧密关联。

字符图描述：

Plaintext

+----------------------+--------------------+
| Column (e.g., Status)| Edit Component     |
+======================+====================+
| Row 1: "Completed"   | <Input /> (FIXED)  |  <- Should be: <DatePicker />
+----------------------+--------------------+
| Row 2: "In Progress" | <Input /> (FIXED)  |  <- Should be: <Select />
+----------------------+--------------------+

❌ 现有限制：一个列绑定一个组件，与行内容无关。
✅ 期望效果：组件根据行数据动态变化。

解决方法：完全自定义单元格

为了突破列组件的限制，实现真正的“行级表单自定义”：

1. 放弃使用自带的 col.edit 属性。
2. 通过自定义表格单元格功能，在单元格内部完全自行实现表单组件的置入、显隐和状态管理。这样，就可以在渲染逻辑中根据当前 row 的数据，自由决定渲染何种表单组件。

---

可编辑表格验证逻辑的不足

在复杂的业务场景中，验证需求往往是有条件的——某些行的某个字段需要验证，而另一些行则不需要。

• 验证的盲区： 当我们调用组件实例方法，例如 validateTableCellData() 进行整表或局部验证时，系统通常会忽略表格 props 中定义的 editableCellState（用于判断单元格是否可编辑）属性。
• 非预期结果： 这将导致即使某一行的某个字段在逻辑上不需要被验证（因为它在当前状态下不可编辑或不相关），该方法仍会返回其验证结果（通常是失败的提示），造成误报。

字符图描述：

Plaintext

Validation Call: validateTableCellData()

+-------------+--------------+------------------+
| Row Index   | Field Name   | EditableCellState| Validate Result?
+=============+==============+==================+
| Row 1       | Amount       | true (Needs Val) | ✅ Yes (Passed/Failed)
+-------------+--------------+------------------+
| Row 2       | Amount       | false (No Val)   | ❌ Still returns a result!
+-------------+--------------+------------------+

问题：即使设置了 'false'，验证函数仍然尝试对该字段进行验证。

解决方法：手动添加验证过滤器

为了确保验证的准确性，即只验证那些确实需要被验证的字段/行：

1. 自行实现过滤器： 在调用 validateTableCellData 等验证方法之前，手动添加逻辑过滤器。
2. 不使用 TDesign 的可编辑表格功能验证