是
Component NameTable, Cascader
Description从2.8版本后很明显的问题就是项目贡献者或作者在解决问题时缺乏整体的思考。
举个例子,2.9版本cascader重写导致的options失去控制(明显的就是不那么容易回填数据了)。该用resolve方式是否可以理解为是为了解决组件props发生改变时导致类似折叠的状态还原这个问题。这种解决方式对于普通table没有太大影响,但是对于需要同步更新table数据就有影响了,而对于异步方式的cascader影响巨大。 你们既然在组件内维护一套自己的数据,是否有想过维护传入数据和组件之前状态更适合用户? 比如table-tree,必须要设置row-key,那么将row-key与row的展开状态关联记录在组件内部。添加一个prop属性作为开关,控制data变化时是否需要应用记录的值来展开之前以及展开的row。 组件内单向维护用户传入数据的做法太偏激,希望有贡献者或团队作者能思考一下。