[table] 关于editableCellState的问题及建议

[wandoupeas]

我有看到新的api(editableCellState)的用法，但是好像跟我描述的有点偏差。

本来我想达到的效果是在columns.edit属性内添加一个控制本列数据是否可编辑的属性，这个属性接受一个响应式的boolean对象或者是一个返回boolean类型的function，function的入参即为PrimaryTableCellParams<T>。

现在是在table的props内添加了一个类似的属性editableCellState，这样目前遇到两个问题：

1. 可编辑行的表格情况下，editableCellState的表现与可编辑单元格的表格的表现相反，返回false现在表现为可以编辑，true不可编辑，这应该是个bug吧。

2. 当我需要根据行数据控制多列属性的编辑状态时，这样个api就显得不是那么方便了，我需要判断当前列的列名是什么，当row中的某个值为什么的时候，来动态返回编辑状态，例如如下代码，这样我觉得不是很方便，所以我还是建议可以在columns.edit中添加一个editable属性，这样编码时也可以在columns中更清晰的看到当前列的可编辑状态

Originally posted by @wandoupeas in #1387 (comment)

[github-actions]

👋 @wandoupeas，感谢给 TDesign 提出了 issue。
请根据 issue 模版确保背景信息的完善，我们将调查并尽快回复你。

[github-actions]

♥️ 有劳 @realyuyanan @Louiszhai @PengYYYYY @chaishi 尽快确认问题。
确认有效后将下一步计划和可能需要的时间回复给 @wandoupeas 。

[chaishi]

第一点，确实反了，有同学提了 PR，会调整

第二点，对于你的需求来说，无非是加个 if 的判断就可以实现相关需求。但是组件库不能只考虑某一个具体的需求。
今天你 需要 控制某一列是否可编辑
明天他 需要 控制某一行是否可编辑
后天她 需要 控制 某一个单元格是否编辑

你觉得在 column 里面编码更清晰，是因为你只看到自己的业务是列编辑控制。（试想，如果 5 列，都需要控制，是不是就要在 5 个地方去写是否可编辑的逻辑，这样的方式，不见得是优雅的）

有更多其他场景的可编辑控制。不能每来一个场景都加一个 API。回头处理同一件事的 API 好几个，也记不住

[chaishi]

第一点，已于 0.20.3 修复