BoxGroup的相关问题, 先记录下

[Exodia]

之前在 qq 讨论群上有过些讨论，这里开个帖子记录一下：

• boxType为 radio 时，getRawValue 返回数组的问题：

首先这个与原生 radio 的行为不一致，另外我建议单选场景的控件都统一为返回单一值。

目前主要遇到个问题就是模块化的场景，一个字段在选项比较少的时候会采用 boxGroup，在选项较多的场景会采用 Select，两者返回的值不一致会导致业务代码陷入很多细节的处理之中。

• 建议对setValue进来的值先进行 stringify 处理。

目前遇到的场景是，后端字段保存的值为整型，目前在 etpl 中，使用@操作符时，是直接取原始值的，当写了以下代码时: data-ui-value="@field"，会导致 value 值为 number 类型，setValue 内部调用value.split时报错。

• 内部的 syncValue 会导致 rawValue 的 value 字段变成字符串，同样造成了业务代码陷入细节处理之中
• setProperties 方法中，对 properties 的 rawValue 和 value 判断使用了 !操作符，会导致边界情况问题：如value 为空字符串的场景。

上述几个问题我暂时会通过在业务代码中继承一个 radioGroup 修复下- -。

[otakustay]

boxType为 radio 时，getRawValue 返回数组的问题

我觉得是应该改成单个值，但这种改动影响会非常大

建议对setValue进来的值先进行 stringily 处理

控件的接口指定value必须是字符串，外部应该负责类型转换，除非你用rawValue

内部的 syncValue 会导致 rawValue 的 value 字段变成字符串，同样造成了业务代码陷入细节处理之中

看上去应该用选中的input的索引与一个暂存的datasource同步来实现

setProperties 方法中，对 properties 的 rawValue 和 value 判断使用了 !操作符

应该修复

[Exodia]

控件的接口指定value必须是字符串，外部应该负责类型转换，除非你用rawValue

我理解接口的设计意图是让外部保证类型一致，不过这样搞的话一个是和原生的一些行为不符合，比如 setAtrribute，以及value的设置会把其他值先转化成字符串，以及在需要字符串的场景都会做 ToString()操作，毕竟 ToString 是可以保证都任何值都能转化为合法字符串的。

而且现在项目中，我感觉很多地方的 value 其实都是非字符串的，因为很多@的存在，只是其他控件恰好没有依赖字符串的某些方法，以及 BoxGroup通过 html 生成的话隐含做了这层转换。

对目前的实际场景的影响上面也说了，@操作符会影响 value 值的类型。

当然这个改动也应该会对现有项目有点影响。

[otakustay]

我认为和原生的并没有不同，你可以不认接口给setValue一些非字符串的值，再通过getValue获取肯定是字符串，你也并不知道原生的DOM元素是在set时转的还是get时转的吧？

整个ESUI控件的值机制被定义为value和rawValue两个，其中前者为字符串，后者为控件自行决定的类型，其转换通过value -> parseValue -> rawValue和rawValue -> stringifyValue -> value进行，这些都是事先严格定义的，我不建议去修改这行为。方法调用方的问题要让被调用方去解决难道不奇怪吗

换句话说，如果我们解决掉“radio的值不应该是数组”后，你是可以用rawValue传值的吧，所以综合来说根本问题就不在这里？

[Exodia]

你也并不知道原生的DOM元素是在set时转的还是get时转的吧?

我觉得作为使用者，其实不用关心 set 转还是 get 转，仅从 input 的表层效果来看，应该是 set 转；但关心的是传入一个非字符串的值是否能够达到 ToString 后的效果，比如原生的 input 来说，我传入非 string 类型的值，是可以达到 ToString 后的效果；w3c 标准应该有这方便的规定，后面我可以去看看- -。

作为 boxGroup这块，目前来说设置非字符串类型肯定是不合法了。只能说在现有项目中，大部分控件的 setValue 兼容非字符串，比如我们项目中用到的Select 控件,都是设置 value，而且 value 很多场景是整数值，但没出现问题仅仅是因为，Select 内部实现 value 的比较用的是非全等操作，导致会进行了隐式转换。

这些控件的处理行为不一致会给使用者带来困扰。

其转换通过value -> parseValue -> rawValue和rawValue -> stringifyValue -> value进行

我认同这个流程，我想的是修改parseValue的行为，在之前先加上一层 ToString(value)，以确保各个控件的行为一致。 因为如果真要修改，要确保目前代码的影响面最小，这个方案应该会比完全不兼容非字符串的 value 来得更适合些。

如果我们解决掉“radio的值不应该是数组”后，你是可以用rawValue传值的吧，所以综合来说根本问题就不在这里？

这个问题解决后，确实是解决了传值问题，但上面只是从这个问题引出的对 value 接口的一些讨论- -。

[otakustay]

我认同这个流程，我想的是修改parseValue的行为

这样的话可以理解

不过根本的问题可能是我们没办法把radio模式的rawValue改成单值了……

[Exodia]

不过根本的问题可能是我们没办法把radio模式的rawValue改成单值了……

我放弃修改 raido 模式改成当值的方案，我目前是写了一个 FlatRadioGroup 的插件，拦截 getRawValue，将返回值直接取数组第一个去搞的

[otakustay]

总觉得加个extension更方便- -