更新: 2019-06-27
select 是原生组件
它的交互体验是这样的 ...
1. 点击, 打开 options
2. 通过 scroll 去寻找 options
3. 或者通过 keyboard 写字, scroll and focus options 位置
4. 选择 （自动关闭）
5. 再打开
6. 选择到空的 options 取消选择.
multiple 的情况 （手机）
1. 点击打开
2. scroll
3. keyboard
4.选择 (不关闭)
5.选择同一个 select 表示取消
6.打开, scroll 查看之前选择过的选项
以上的交互体验对比 chips autocomplete 少了一些常见的需求
1. 资料多的时候, 通过 scroll 和 keyboard 很难定位.
2. 资料多的时候, 我们需要获取大量的数据和显示大量的 element, 这样会很卡
(虽然可以用 lazyload + virtual scroll ... 真的是大费周章丫)
3. 多选的时候，在不打开 select 的情况下无法知道选项.
目前 material 的 select 是依据原生 select 做体验的，所以以上的问题都有.
https://github.com/angular/components/issues/5697
https://github.com/angular/components/pull/7835
https://github.com/angular/components/issues/10122
很多人都不喜欢 select 的 scroll 定位这种交互体验.
大家更喜欢用 filter 来取代.
我个人觉得这 2 个体验是不一样的需求, 并不能互相替代.
scroll 的好处是你可以继续上下查找, 找附近的。
filter 则不可以这样. 但 filter 会让 element 变少, 需要的数据也少
就不需要 virtual scroll + lazy load 了.
以目前的组件来看，chips autocomplete 是最接近我们需求的
它用 input 作为开始, 用户写字, filter 出 options 然后选择.
在 multiple 时, 也可以一览所有 selected item
chips autocomplete 对比 select 的缺点是它给人一种 multiple 的感觉.
即便你只是要 single select
还有就是在 multiple select 时, 它不像 select 那样会一直把 options 开着.
当然你可以改，但是由于它的特色是显示所有 selected， 如果让用户连续添加 options
由于 selected display 不断增加就会导致它变高, 这样会突然跳一下, 用户很可能会 miss action。
所以这不是个好的设计.
还有呢，它的 options 不会hight light 你选中的选项，当再选时也不会 unselect
这和 select 也是不同的.
最终...这 2 个组件依然不可以相互替代. 也不可以符合所有场景.
除了这 2 个组件，还有一个叫 menu 的组件也和它们很像。
我觉得最大的区别在于 menu 不是 form control
select 是 form control
chips list 是 form control
但是 menu 缺不是...
所以直到今天我依然没有一招打天下的方法. 每隔段时间就来重新思考一下呗。
记入一些思考 :
这 2 个组件有点像，经常会搞混.
select 的定位是选择. 目前 select 最糟糕的一点是 not search friendly。
还有当需要 multiple select 很多很多时, 一定要打开 options 来 unselect, 操作不友好.
再来就是如果 option 数据很大的话, 也不行.
有比较才有伤害，上面的不足是对比 autocomplete 才出现的.
autocomplete 的定位是帮助我们完成我们的 input 输入.
范围很小，只是 input text.
经常让我们搞混的原因其实是 autocomplete + chips
这个组合的用法是, autocomplete 作为 search input, 然后选择后放入 chips 里, 再通过 chips 来做移除.
这姐夫可以模拟 select 了.
所以目前通常当我们要用 select 但有遇到上面说的不 friendly 场景时，可以 autocomplete + chips 来模拟一下下.