[Select组件] label为0的时候无法显示 about tdesign-react

[NWYLZW]

如果label强制要求是string类型的，使用数字类型应该报warning进行提示 这里的数字类型1是可以显示的，数字类型为0显示不了，是一个非常明显的问题 真正能暴露使用问题的方式是进行warning提示，而不是使用者使用同一类型的数据的时候显示出与其他数据不同的行为 这很容易导致难以预料的业务问题

首先数字的输入是 ub(unspecified behavior)，其次如果你使用的是现代化的编辑起在类型上便会对类型进行检查，并不会遗留问题到生产环境再被发现。

如果你确实觉得组件库需要来对这些 ub 做防御型编程可以提出一个 feature request，关于如何对于 falsy(undefined,null,0,false) 的各种特殊情况下对于数据输入的转化逻辑，这可以被讨论应该如何防御，而且这对于整个系统来说都是有益的。

[github-actions]

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

[HaixingOoO]

label使用string

[suedar]

不能这样单纯的处理，有的options是依赖后端返回的，这样很容易出现业务问题，至少应该兼容一下。。。

[NWYLZW]

options={options.map(i => ({ label: i.label || '无', ...i }))}

[NWYLZW]

不能假定在使用的用户需要的就是什么，可能是需要隐藏，可能是需要展示文案（文案也是不确定的），万一有的依赖就是不展示呢（可能性比较小）
基于以上的观点，如果我兼容了，问题就不会暴露出来，可能作为一种默认行为被继续使用
其次如果你需要对于 falsy 的特殊兼容支持，这可能是一个比较大的需求，对于单一职责的原子组件来说引入过多复杂度对于组件的维护并不是一件好事
最后由业务向后端要求数据格式的准确性，也是后端应该做到的
所以说约定了 string 的情况下，对于 only string 的支持也是一种合理的措施

[suedar]

如果label强制要求是string类型的，使用数字类型应该报warning进行提示
这里的数字类型1是可以显示的，数字类型为0显示不了，是一个非常明显的问题
真正能暴露使用问题的方式是进行warning提示，而不是使用者使用同一类型的数据的时候显示出与其他数据不同的行为
这很容易导致难以预料的业务问题