Element: [Feature Request] Questions about the Solution of Element-ui Component Library(关于element-ui组件库解决问题方式的质疑)

Created on 8 Jul 2019  ·  17Comments  ·  Source: ElemeFE/element

Existing Component

Component Name

Table, Cascader

Description

从2.8版本后很明显的问题就是项目贡献者或作者在解决问题时缺乏整体的思考。

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

Most helpful comment

首先,感谢您对element-ui的支持。

关于您所说的「从2.8版本后很明显的问题就是项目贡献者或作者在解决问题时缺乏整体的思考」我并不是十分认同。

2.8+的更新主要包括两部分,一是如Backtop、Image、InfiniteScroll 等新组件,二是像 Cascader、Table 等这种在原来组件基础上的新需求。所有的更新都是为了让 element-ui 在保证可维护性的前提下更好的服务于使用者进行的。在开发新需求的时候,我们发现,有部分组件如 Cascader、Table,由于早期设计比较狭隘,历史包袱重,可拓展性不强,严重影响了新功能的开发以及可维护性,甚至性能,所以不得不作出重构的决定。在重构时,我们尽量避免 API 上的 Breaking Change,都尽量兼容了老的使用姿势。虽然确实引出了一些新的问题,但我认为,正是因为我们有整体性思考,所以才选择重构。不知道这和您所理解的「整体性思考」是不是有所不同。

另外,你上面提到的 Cascader 动态加载数据的问题,您依然可以通过 options 进行控制, 而新的 lazyLoad 是一种更优解,方便对组件的加载状态进行控制,这和 Tree 动态加载的设计是一致的,不明白您的疑虑点在哪里。

如若我有理解错的地方,烦您提供相关 Demo 来进行说明。

All 17 comments

Translation of this issue:

Existing Component

yes

Component Name

Table, Cascader

Description

The obvious problem after version 2.8 is that project contributors or authors lack overall thinking when solving problems. For example, the 2.9 version of cascader rewrite causes options to lose control (obviously it's not easy to backfill data). Whether this resolve approach can be understood as a solution to the problem of folding-like state restoration when component props change. This solution does not have much impact on ordinary tables, but it has an impact on the need to update table data synchronously, and has a huge impact on cascader in asynchronous mode. Since you maintain a set of your own data in components, have you ever thought that maintaining the state before the incoming data and components is more user-friendly? For example, table-tree, row-key must be set, then row-key and row expansion state are recorded in the component. Add a prop attribute as a switch to control whether the recorded values need to be applied to expand the row before and when the data changes. It's too extreme to maintain user's incoming data unilaterally in a component. I hope contributors or team writers can think about it.

首先感谢你的反馈。


Table 的新功能是我添加的,说一下 Table 。
API 的设计都是由实际需求来驱动的。比如你说:

控制data变化时是否需要应用记录的值来展开之前以及展开的row

从用户的反馈中,保留展开状态更普遍,参考 #14933。
如果部分 API 设计不合理,提交 feature request,详细说明你的需求。

我觉得通过暴露方法交给使用者自己去控制比较合适;
目前我也在tree table上遇到了许多问题。
1.删除树表格的子树,使用新的列表给表格赋值,删除的子树依然存在
2.改变页面大小pageSize、使用搜索功能,我不希望表格“记住”展开的项,而是都默认关闭

上面的问题我还在寻求解决办法!

借贵地问一下在electron-vue中,使用[email protected]中的table组件渲染正常,超过2.8.2版本号则在无数据时可显示,有数据时整个组件不可见

我觉得通过暴露方法交给使用者自己去控制比较合适;
目前我也在tree table上遇到了许多问题。
1.删除树表格的子树,使用新的列表给表格赋值,删除的子树依然存在
2.改变页面大小pageSize、使用搜索功能,我不希望表格“记住”展开的项,而是都默认关闭

上面的问题我还在寻求解决办法!

提供一个 demo 吧。

借贵地问一下在electron-vue中,使用[email protected]中的table组件渲染正常,超过2.8.2版本号则在无数据时可显示,有数据时整个组件不可见

2.9.0 也没有啥特殊的,提供一个 demo 描述你的问题。

首先感谢你的反馈。

Table 的新功能是我添加的,说一下 Table 。
API 的设计都是由实际需求来驱动的。比如你说:

控制data变化时是否需要应用记录的值来展开之前以及展开的row

从用户的反馈中,保留展开状态更普遍,参考 #14933。
如果部分 API 设计不合理,提交 feature request,详细说明你的需求。

嗯,如果没记错的话,tree-table这个新特性是之前你给官方提过的,最后你自己实现并提交了pr的。 
首先非常感谢你的贡献(我个人比较懒,大部分问题其实可以自己解决的,只是在已有组件的情况下不想再另起炉灶)。
我上面主要是举得例子,关于table的述求上面那位仁兄也表达了部分的想法。
另外关于这个开关的具体说明如下:对于大部分场景,数据变化导致之前展开的行收起并不是他们期望的,所以开关默认开,也就是组件更新自动应用之前记录下来的状态和数据之间的联系。但是不是所有情况下用户都希望保持之前展开的状态的,比如希望table初始化。这样通过设置这个开关为关闭来禁用状态与数据的联系。
本意是将数据和组件api的控制权尽可能多的交还给用户,我们只需要帮他们实现这些api。
(ps:不建议组件内单向维护数据既不反馈给用户也不接受用户控制。个人非常不赞同用resolve方式,这打破了单向数据流理念,当然修改的是内部维护的数据也不算违规)

另外cascader不知道是受什么启发在2.9也改成了resolve方式,这个问题上面也提过,也有很多人提问题反馈了存在的问题。对比vue-ant-design的cascader,还是维持的element2.8版本的实现方式。options作为唯一数据源。可以避免很多问题。整理部分人的意见就是,他们需要的是2.8的cascader关于异步请求操作options的更详细的说明,而不是让组件代理这个处理。

啥时候官方的 表格,select下拉 和 el-tree 树形菜单能支持 10000+ rows 不卡顿渲染啊

首先,感谢您对element-ui的支持。

关于您所说的「从2.8版本后很明显的问题就是项目贡献者或作者在解决问题时缺乏整体的思考」我并不是十分认同。

2.8+的更新主要包括两部分,一是如Backtop、Image、InfiniteScroll 等新组件,二是像 Cascader、Table 等这种在原来组件基础上的新需求。所有的更新都是为了让 element-ui 在保证可维护性的前提下更好的服务于使用者进行的。在开发新需求的时候,我们发现,有部分组件如 Cascader、Table,由于早期设计比较狭隘,历史包袱重,可拓展性不强,严重影响了新功能的开发以及可维护性,甚至性能,所以不得不作出重构的决定。在重构时,我们尽量避免 API 上的 Breaking Change,都尽量兼容了老的使用姿势。虽然确实引出了一些新的问题,但我认为,正是因为我们有整体性思考,所以才选择重构。不知道这和您所理解的「整体性思考」是不是有所不同。

另外,你上面提到的 Cascader 动态加载数据的问题,您依然可以通过 options 进行控制, 而新的 lazyLoad 是一种更优解,方便对组件的加载状态进行控制,这和 Tree 动态加载的设计是一致的,不明白您的疑虑点在哪里。

如若我有理解错的地方,烦您提供相关 Demo 来进行说明。

image
我用在线主题生成器,改了下颜色,把element-theme文件复制到工程里,然后el-cascader样式就乱了,一级、二级、三级怎么都列出来了?

@element-bot 代码如下:
<el-form-item label="地址区域" prop="areaId"> <el-cascader :options="cityOptions" class="w_per100" expand-trigger="hover" :props="props" v-model="form.areaId" size="medium" filterable /> </el-form-item>

@SimonaliaChen 帮忙看下我的问题,谢谢

@SimonaliaChen 帮忙看下我的问题,谢谢

没有复现 麻烦检查下你安装的element-ui的版本 是否和在站点生成的theme保持一致?

@SimonaliaChen 谢谢,以上问题按照你说的方式已解决;但是,又出现了一个新问题:项目里 el-table 表格咋又全不显示了?是新版本有变动吗?

@SimonaliaChen 谢谢,以上问题按照你说的方式已解决;但是,又出现了一个新问题:项目里 el-table 表格咋又全不显示了?是新版本有变动吗?

这个你去单独提个issue吧 提供下复现Demo

Was this page helpful?
0 / 5 - 0 ratings