封面图
从平台上眺望妙峰山，别有意境。
钗头凤
红酥手，黄藤酒，满城春色宫墙柳。东风恶，欢情薄，一杯愁绪，几年离索，错、错、错。 春如旧，人空瘦，泪痕红浥鲛绡透。桃花落，闲池阁，山盟虽在，锦书难托，莫、莫、莫。
这首词是南宋词人陆游所作，之前似乎也读过，但对这首词所表达的意思却不十分明确，昨天无聊的时候翻了翻，发现了一些有意思的故事。
陆游，字务观，号放翁。务观二十余岁，于山阴游沈氏园时，遇其故妻唐氏，故作此词。
这里有一个故事说的是陆游年轻的时候，家里人对他的学业管教的非常严格。虽然早早结了婚，并且夫妻二人感情非常好，但是父母怕他学业无所长进，所以几次三番的催促他去游学，陆游不违背长辈的意愿，和妻子做了诀别。
多少年之后，陆游的妻子改嫁给了一位据说赵姓的官宦人家。一天，陆游在沈氏园中游玩，遇到了前妻，前妻为他准备了美酒佳肴，放翁怅然，赋词一首：红酥手、黄藤酒...
最终有山盟虽在，锦书难托的怅然。
什么是好的组件
在前端开发领域，组件封装是一件比较重要的事情。因为现代前端的业务越来越基于组件进行开发，我们可以发现，除了少有的非常老旧的项目之外，其他的项目可以说基本上都是基于组件进行开发的。
那么，如何封装一些比较好的组件呢？
首先我们需要弄明白的一件事是：什么是好的组件？什么样的组件才是好组件？
其实在我看来，组件其实并没有好坏之分，一言以蔽之，能够满足业务需求的组件就是好组件。
我们需要弄明白的另一件事儿是：组件的好坏是由谁来定义的？
这个也很简单，组件的好坏是由组件的使用者来定义的。
如果我们开发了一个或者一些组件，十个人用了都说好，那么我们开发的这些组件必然有它好的地方。
从使用者的角度来评价组件的好坏可以从以下几个方面来看：
- 组件的样式是否美观
- 组件的功能是否齐全
- 组件是否可扩展
- 组件文档是否明了
- 组件是否有简单的用例
其实这些我们都可以参照开源的组件库进行组件的开发和文档的编写，比如：antd 的文档
用例和API在文档中描述的非常清晰，这样组件的使用者就可以非常快速的查找对应的组件，快速迭代业务，所以外部对这些组件库的评价就非常高。
假设我们开发了组件，并且在自己的业务中也有很多地方用到了这些组件，但是我们的组件虽然定义了一些属性，比如：列表中常用的options这个属性，我们虽然在组件中定义了它是一个数组，但是也仅仅是定义了如下的写法：
props:{
options:{
type:Array,
default:[]
}
}这肯定不是一个好的写法，因为我只知道options是一个数组，数组中的元素是什么类型我们并不知道，有可能是字符串，数值，对象或者别的什么类型都有可能。
在实际使用的时候如果负责迭代业务的同学不知道这个options数组接收的数组中元素类型的话，写起来就回非常麻烦。
所以，如果在项目中我们无法使用ts作类型限制的时候，在开发组件时，我们需要用一些其他的形式，尽量将这个组件描述清楚，比如注释、文档。
让用到这个组件的同学不用去重新翻来覆去的找这个组件中的参数要是什么类型，有哪些字段等等。
说了这么多废话，其实总结起来就一句话：满足业务需求，并且能让组件的使用者使用起来觉得舒服的组件就是好的组件。
至于组件如何封装，不同的人有不同的实现方式。
