[Enhancement] [select] select等组件的功能完全不考虑用户的实际需求

[keypadDancer]

Feature type: Enhancement

Details

• Enhanced component name: select

Description

我就想知道产品经理和项目负责人怎么想的
我举几个非常实用的痛点
比如el-select，我不知道为什么popper展开状态下，我点击select，popper又会收起来？这样设计的原因是什么？这种设计极其不合理。
举个例子，我现在是el-select，filterable设置为true，也就是可过滤情况下，我现在输入我想查找的关键字，结果呢中间有个字输错了，我现在想鼠标点击把光标移动到我输错的哪里，结果我一点击popper就消失了，我输入的文字也全没了。为什么这样设计？很合理吗？
为什么我el-select选中的label我没有办法像普通文本那样任意的选中复制？我一点击select，文本就变成了灰色并且无法选中，为什么这样设计？很合理吗？我不能从我选中的选中的label中复制一部分文字粘贴到其他地方使用，提高我的效率吗？
还有既然已经有tag多选了，就不能单纯做个tag输入框吗？就只输入tag，popper不会出现，有点类似于tag和自定义创建条目的结合，这样我可以用于多条件筛选啊，非常简单的一个功能

好，我再来说table组件
table组件既然提供了type=selection的选项，就不能把他做完善吗？
当type=selection时，我先选中第一个，然后再按住shift选中第10个，那为什么不能直接帮我把1-10全选中呢？
反过来也是一样的，当我1-10是选中的，当我取消了第一个选中，然后按住shift取消选中第10个，那为什么不能帮我把1-10全取消掉？
这是最基本的一个功能了，拜托。如果这个功能你不懂我在说什么，你可看看qq邮箱，按照我说的操作步骤去试试，你就知道我再说什么了。

然后项目负责人来看
为什么我们所有和虚拟滚动相关的组件，都是普通滚动是一个组件，虚拟滚动是一个组件？
为什么我们不能首先写一个虚拟滚动的组件，然后其他组件都在这个虚拟滚动的基础上来做，然后只做一个，通过传入的属性去判断要不要虚拟滚动？

我们的复杂组件能不能是使用我们的基础组件组合起来的？
比如我们写个基础的日历组件，这个组件就可以给用户单独用，然后el-date-picker就是select和date组合起来，我需要然后我可以按照date和select的prop去定义我的el-date-picker中的select和date部分？

我觉得这个代码组织和组件化的有很大的提升空间

The following is a machine translation of the original text

I just want to know what product managers and project leaders think.
I'll give you a couple of very practical pain points
For example, el-select, I don't know why when the popper is expanded and I click on select, the popper will be closed again? What is the reason for this design? This design doesn't make sense.
For example, I'm in el-select, filterable is set to true, that is, filterable, I'm typing in the keyword I want to find, the result is that there is a word in the middle of the wrong, I want to mouse click to move the cursor to where I made a mistake, but the result is that when I click on the popper, it will disappear, and all the text I typed in will be gone. Why is it designed this way? Does it make sense?
Why can't I copy my el-selected label as I would a normal text? As soon as I click on select, the text turns gray and cannot be selected. Is it reasonable? Can't I just copy a portion of the text from my selected label and paste it somewhere else to increase my efficiency?
And since there is already a tag multiselect, can't I just make a tag input box? Just enter the tag, the popper will not appear, kind of like a combination of tag and custom created entries, so that I can be used for multi-criteria filtering ah, a very simple function!

Okay, let me come back to the table component.
The table component provides a type=selection option, can't we make it better?
When type=selection, I first select the first, and then hold shift to select the 10th, so why not just help me to 1-10 all selected?
The reverse is also true, when I have 1-10 selected, when I uncheck the first one, and then hold shift to uncheck the 10th one, why can't it just uncheck all 1-10 for me?
That's one of the most basic features out there, come on. If this function you don't understand what I'm talking about, you can look at the qq mailbox and try the steps I'm talking about and you'll see what I'm talking about.

Then the project leader looks at
Why is it that all our components related to virtual scrolling are one component for normal scrolling and one component for virtual scrolling?
Why can't we first write a component for virtual scrolling, and then all the other components are done on top of that virtual scrolling, and then just do one, and use the incoming properties to determine if we want virtual scrolling or not?

Can our complex components be assembled using our base components?
For example, if we write a basic calendar component, this component can be used by the user alone, and then el-date-picker is a combination of select and date, I need to and then I can define the select and date part of my el-date-picker according to the prop of date and select?

I think this code organization and componentization has a lot of room for improvement

Additional comments

(empty)