select中判断options更新疑问

[goo-yyh]

Which Component 出现bug的组件

• Select

semi-ui version

• latest

仅比较一层children的key，如果有option-group，group下的options变更是否检测不到，因为group的key是相同的

[goo-yyh]

大哥，还有个问题：虚拟化时候，不支持optionGroup是基于什么考虑。

[pointhalo]

Which Component 出现bug的组件

• Select

semi-ui version

• latest

仅比较一层children的key，如果有option-group，group下的options变更是否检测不到，因为group的key是相同的

对。这里会有一个使用约束，主要考虑到里不希望在didUpdate去做递归判断。

[pointhalo]

还有个问题：虚拟化时候，不支持optionGroup是基于什么考虑。

1、Group与option的高度不相同，做虚拟化的化要实现不定高虚拟列表，相当繁琐一点
2、在我们的业务场景里，这样用的频率很少。因此没有实现。

[goo-yyh]

谢谢大哥，那其实在收集的时候照现有逻辑最多只会收集到两层，第一层children是group，第二层就是options。
结合实际使用的场景下，options都是从请求中获得。使用方在获取data后，无论数据是否更新，由于在这个约束下，必须给group赋值一个新的key，即使数据没改变，也会触发optionsChange。

[goo-yyh]

谢谢大哥，那其实在收集的时候照现有逻辑最多只会收集到两层，第一层children是group，第二层就是options。 结合实际使用的场景下，options都是从请求中获得。使用方在获取data后，无论数据是否更新，由于在这个约束下，必须给group赋值一个新的key，即使数据没改变，也会触发optionsChange。

是不是因为group在实际应用中较少。

[pointhalo]

【无论数据是否更新，由于在这个约束下，必须给group赋值一个新的key】没太get到为什么数据不需要更新时，必须给key。如果你的group title以及它的children并没有更新，不会触发optionsChange呀。

[goo-yyh]

【无论数据是否更新，由于在这个约束下，必须给group赋值一个新的key】没太get到为什么数据不需要更新时，必须给key。如果你的group title以及它的children并没有更新，不会触发optionsChange呀。

没事了，蟹蟹大哥，确实group的场景比较少。
我的意思是，使用时前后两次从接口获取到data后，由于不知道两次data有没有变化，使用方为了保证select视图更新，就得给group重新生成一个key。

[pointhalo]

如果你不确定数据来源是否变更，那是需要。但是对于组件级别来说，这类变更判断是有必要的。属于你不告诉我需要更新，那我就不会主动更新的场景。

btw，我把这个issue转成discussion了。