iview的一个小bug issues #4371

为什么80%的码农都做不了架构师？>>>   

最近更新的iview3的速度已经上去了,而且我通过自己打包编译,已经将其它不需要的组件去掉,只留下了select和相关的子组件,因此体积也小了不少.
之前提到过,这个组件在使用过滤和分组的时候会有bug.我已经提到了github上,但人家未必愿意修复,即使修复,也要等很久,因此,我决定自己来搞.今天还算顺利,搞出来了,下面是修改后的代码.
                    

if (this.filterable){
                            children = children.filter(
                                ({componentOptions}) => this.validateOption(componentOptions)
                            );
                        }

                       //cOptions.children = children.map(opt => {
                        children = children.map(opt => {
                            optionCounter = optionCounter + 1;
                            return this.processOption(opt, selectedValues, optionCounter === currentIndex);
                        });

                        // keep the group if it still has children
                        //if (cOptions.children.length > 0) selectOptions.push({...option});
                        if (children.length > 0) selectOptions.push({...option,componentOptions:{...cOptions,children:children}});
                    } else {

已经提交了pull request
在这里,用到了一个js的新的操作符,...(三个点)这三个点是用来解构一个对象用的.
这里出现的问题是比较常见的,就是通过修改对象本身的属性来实现数据的变化,但是,修改了对象本身,原始的数据发生了变化,就无法重现初始状态了.因此这种直接修改对象属性的方式肯定是不合适的.(iview通过computed获取属性的设计说明在一开始已经想到这一点了,只是内部实现的时候的小疏忽吧)每次遇到这种引用被修改的情况,往往想到的是将引用变成复制,clone,但是js处处是引用导致不论用什么方式(考虑过逐层复制,json字符串化)都会陷入循环的境地.但是这里所使用的...能够将大对象的部分内容进行重载并返回,并不对原对象内容进行修改.当然,返回的没有重载的部分可能还是原先的引用,因此,在对返回内容进行不修改的引用还是有意义的,如果修改了,很有可能还是出现这种问题.
通过这种方式对部分成员进行重载,而且是多级重载,挺方便的.

转载于:https://my.oschina.net/rodger/blog/1942152