基于自己工作中的体会，还有在做的过程中翻阅的资料，看的资料没有收藏起来，很想指出具体的出处，但是很多都是从各个地方看到的。不过都是在掘金、公众号前端开发、还有知乎上看到的。
😫 前言
随着web业务越来越复杂，一个页面必须要分成多个部分才能使得代码逻辑更加的清晰，出了问题也能更加快速的定位。所以说如果分组件的重要性不言而喻。
一、基本原则
- 每个组件不能超过300行:网上看好多人都说是200行，但是那样实际操作的话，压力会很大的，导致很多时候会为了分组件而分组件。其实分组件的目的就是为了可读性和可维护性。为了分组件而分组件的话，很多时候写的会很散很乱，违背了分组件的原则。 一切都是为了可读性和可维护性 组件有两种类型：一种是有状态的，一种是无状态的 从不同纬度考虑的话，可以分为四种：逻辑组件（智能组件）、UI组件（木偶组件） 、路由组件、状态组件（当前工作环境等常量） 业务代码的复用高于代码的复用* 公共组件可以有自己的方法，但是数据的展示依旧是拿props。一定要在跨页面使用的情况下才放在主目录的componets中> 无论是Vue、augular还是React提倡的基于数据驱动的设计理念——程序定义好Model和View的关系，剩下的业余处理只需要关心数据变化，View的变化由框架自动执行，无需像jquery时代再去手动操作DOM。
| 展示组件 | 容器组件 |
|---|---|
| 关注事物的展示 | 关注事物如何工作 |
| 可能包含展示和容器组件，并且一般会有DOM标签和css样式 | 可能包含展示和容器组件，并且不会有DOM标签和css样式 |
| 常常允许通过this.props.children传递 | 提供数据和行为给容器组件或者展示组件 |
| 对第三方没有任何依赖，比如store 或者 flux action | 调用flux action 并且提供他们的回调给展示组件 |
| 不要指定数据如何加载和变化 | 作为数据源，通常采用较高阶的组件，而不是自己写，比如React Redux的connect(), Relay的createContainer(), Flux Utils的Container.create() |
| 仅通过属性获取数据和回调 | |
| 很少有自己的状态，即使有，也是自己的UI状态 | |
| 除非他们需要的自己的状态，生命周期，或性能优化才会被写为功能组件 |
二、组件实例（反面例子）
2.1 分享组件
功能： 一个弹框，弹出需要分享的类型、有微信好友、朋友圈、链接微信好友、短信、还有海报生产的路由带参跳转。
变量: 按钮的类型、分享出去封面的样式、分享出现带的参数（h5和小程序由于历史原因还是有一些不同的）
文件结果还是很乱的，这是由于本来最外层只有一个index.js，随着开发发现要判断的东西越来越多，所以把他逻辑都拆分了。
- assets: 常量、参数的封装、工具库* images: 图片库* renders: 业务组件夹，三种分享类型的不同的封面样式和一个分享标题的组件* styles: 样式库* Contianer: 容器组件，把组件的三个部分的组件都包含在外* ButtonMain* CoverView* TitleVIew
- index.js: 逻辑组件，所有逻辑的操作都在这里，参数的封装太多分离到了assets中* ShareWechat: 封装的原生微信SDK分享容器组件:
逻辑组件（智能组件）:
通过容器组件爆出的props来进行控制容器组件的逻辑。
2.2 页面组件
- index: 主页功能
- pages：该房地产功能的其他页面
- componet: 该功能的公共组件
- renders: 主页的业务组件，由于主页内容太多分离出去的
即使分离来页面的各个功能，但是单单是这样引入依旧够多且长的。本来这个是我想要再分离出去。但是一想到要props这么多参数，反而影响来可读性。所以这个组件超过来500行代码。写代码的时候，不管碰到了什么问题，如果影响到了可读性，而自己会一时半会没想到怎么解决，或事件来不及的时候。永远要选择可读性。
对于组件中方法的复用:
<shareModule ref={(ref) => this.shareModuleHandle = ref}/>
// ...
test = () => {
this.shareModuleHandle.manHdele() //
}
三、其他心得
之前我一直认为 代码的重复是罪恶的，是让人唾弃的！ 但是看了知乎这篇文章，我发现我好像偏离的轨道，代码的封装是为了代码更容易的去维护。有一种幡然醒悟的感觉。醍醐灌顶一般！
在知乎搜索“前端写代码真的有必要封装太好么？”
觉得很好的两个问题：
- 人的精力是有限的，多考虑大的价值。我现在在面对这么封装，是否应该封装的过程中，耗费的时间确实不少，这样是否是对的呢？肯定不是坏的，但是是否是现阶段最有意义的呢？
- 你现在写的代码，不管公司怎么样，只要你还在写，那么你就要对自己写的代码负责。“你写的项目，你做的项目很有可能在下一个季度交给另外一个人维护，我希望接受代码的人不会在背后骂你”，多想想你未封装的代码会对他人维护带来困扰吗？
最后
整理了75个JS高频面试题，并给出了答案和解析，基本上可以保证你能应付面试官关于JS的提问。
有需要的小伙伴，可以点击下方卡片领取，无偿分享
