Angular由一个bug说起之十九：Angular 实现可拓展 Dropdown 组件

目录：

1. 项目中的 Dropdown
2. 简要分析需求
3. 设计方案
4. Demo 展示
5. 验证

项目中的 Dropdown
我公司的项目中实现过不止一个 Dropdown 组件，但是普遍存在一些难以解决的痛点。又或者在实现的时候能满足需求，但是一旦功能修改了就很难拓展。这也是写这篇文章的原因，主要是想找出一个比较好的解决方案。
以下我列举一些项目中典型的问题以及它们出现的原因：

1. 多份 options 备份
2. 多组件复合
3. 复杂的组件嵌套

多份 options 备份
这个问题最先出现的原因是我们引入了检索功能。被检索的 options 是不完整的列表，当我们需要从列表中筛选出被选中的选项来改变它们的状态时需要一个完整的 options。所以此时就多了一个 filteredOptions。
而后随着功能越来越复杂，这类的 options 备份也越来越多，甚至曾经一度达到了 4-5 个。

多组件复合
一开始我们只需要实现一个单选下拉框和一个复选下拉框。而后功能增加例如: lazyload options，配合其它功能的Switch开关，Search 输入框 等。
这就造成了组件的布局问题，以及各个功能之间的通信复杂度也上升了。慢慢的 Dropdown 的体量变的越来越大，它的维护难度也直线上升。

复杂的组件嵌套
我们一开始实现的单选和多选 dropdown 还是有很多可以复用的组件和样式的。后期二者的区别越来越大，共用的组件慢慢变的不再共用。所以项目中出现了很多的 if else 来区分这两个组件的应用范围。
同时这两个组件当时是嵌套在同一个组件中，因为它们有类似的数据流，可以共享通信过程。但是这也为后期的功能拓展埋下了隐患。

---

综上所述，正因为存在这样的问题所以我们需要一个更好的 dropdown。为下次项目重构提前做出准备。

简要分析需求
Dropdown 组件可涵盖的业务非常广泛，要具有 和业务解耦，扩展性强，好维护 等特性。我们列出不同视角下，组件的特性和规律，方便我们制定方案。

组件有什么？
以 Angular component 为例，一个组件至少需要以下 4 点：

1. input
2. output
3. UI (html, css)
4. functions (event, method …)

这 4 点可以归纳为：

1. input AND output --> Model
2. UI --> View
3. functions --> Controller

如何解耦
由此可见，实现一个扩展性强的组件我们需要做的是：协调好 mvc 的逻辑，明确 mvc 的代码应该放在哪些文件里，用什么形式实例化组件。
那么，为了实现解耦，为了能以 API 热插拔的形式实现组件的拓展，就有一个核心的要求：Dropdown 中的每一个小功能要以一个 独立的，完整的 包含全套 mvc 的组件形式存在。

用代码表示类似于：

<!-- Dropdown UI -->
<div class="dropdown">
  <SearchInput></SearchInput>
  <DropdownMenu></DropdownMenu>
  <DropdownBtns></DropdownBtns