昨天我在一个群里有一个人在问，谁会 rxjs？我当时其实还有点好奇，对于 rxjs 我一直觉得很难，前阵子我也一直在研究。
Rxjs 我也一直觉得挺有用的，但是身边用 rxjs 的朋友真的很少，我司的项目也是根本没有。
所以我听到有人问 rxjs 的问题，我就特别激动，就问了他什么问题，他说刚接触 rxjs，然后看源码遇到一端代码看不懂。
我当时心想，还有这种操作的么，还没学会怎么使用就开始看源代码了，然后他就把他不懂的代码贴了上来，rxjs 源码是 TS 写的，我对 TS 不算太熟悉，但是他贴的代码我还是能看懂，他就问了个 this 的问题，我看着也很简单，但是我没有解答他的问题。
原因有两点：
- 态度不好，我不喜欢。我跟他说你如何去学习 rxjs 的源码，然后给他介绍书（程墨的《深入浅出 RXJS》）。他直接回复我，你会不会，我就想知道这个问题，不知道就别 BB（大概就是这意思），所以我直接回了他，不会。
- 自以为是。他问的问题其实很简单，虽然 Rxjs 源码是 TS 写的，我对 TS 也不是很熟悉，但是这点代码我觉得还是比较简单的，然而这没看懂，然后还在没有上手怎么使用，就开始搞源码，还不听人建议，这纯属自以为是，觉得看源码才是王道。对于这种纯属基础没打好，就开始搞高端的，走都没学会就想学跑。
那么我们如何正确的学习一个框架，什么时候该看源码，学到什么程度再看源码呢？
我觉得学习一个框架应该分为三个程度。
- 学会使用
- 熟悉框架的设计思想、关键部分的实现思路以及整个框架的知识体系
- 源码解读以及造轮子
我以学习 React 为例来介绍如何学习一门框架(库)
学会使用
这个程度我相信是大部分人所处的阶段，熟练使用 React 的 API，熟悉 JSX，各个声明周期的使用，以及组件之间(父子、子父、兄弟等)如何传递消息，高阶组件等。
这就相当于入了门，可以完成一般的业务了。
熟悉框架的设计思想、关键部分的实现思路以及整个框架的知识体系
设计思想 众所周知，React 是一种组件化的解决 UI 构建的一种方案，横向比较同类型的 Vue ，也是组件化的一种解决方案（这体现了 react 抽象的设计思想），既然是组件化的思想，那么这种解决方案，理论上都会有组件的生命周期，来处理组件从创建到销毁的钩子函数。
React 也是一种声明式的解决方案，通过数据驱动来改变 UI，从而有 UI = f(state)。
当然 react 还有其他的设计思想，比如组合（各个小组件的组合成大的页面，这些小组件都是通过组合来达到复用的效果），单向数据流。
关键部分的实现思路 React 的重点概念有 JSX，虚拟 DOM，Diff 算法，setState 机制，这些重点概念自己是否能有他们的实现思路，甚至在没有看源码的情况下是否能自己根据思路实现出来。
这个可以看看胡子大叔写的blog,[从零开始实现一个React](GitHub - hujiulong/blog: 我的blog)。
整体框架的知识体系 已经能熟练使用，也掌握了改框架的重点知识，是否能梳理出整个框架的知识体系，把每个知识点串起来，形成一张 react 知识网，网的每个节点都是一个知识点，连线就是他们之间的关系。
这个阶段基本上应付面试没啥问题了。
源码解读以及造轮子
这个源码解读基本上可以看做终极奥义了，其实大多数情况并没有必要去解锁这个终极奥义，因为源码解读确实比较费时间，特别是对于基础不牢固的同学，看几行代码就有看不懂的，又得去查资料搞懂。
对于文章开头提到的那种行为真的不提倡，作为一个前端，要学的知识那么多，每个都去看源码实现，哪里有那么多时间，不如好好想想怎么用现有的知识更好的去解决业务问题。
然后明白技术是为业务服务的，如果没有业务，技术将是无稽之谈。然而在我们大多数场景下，我们的业务是没有必要去造个轮子来解决，因为对于 react、vue 这种库来说，已经是非常的通用了，能解决 95% 以上的业务。
当然也有这些开源框架解决不了的问题，比如我有个业务是需要写一套代码，多端可以用的，比如写 vue 代码，这套代码也可以转换为 小程序代码，甚至是 Android 原生 、IOS 原生代码等，那么这个时候我们就必须得去看源码，才能更清晰的知道源码是怎么去处理每一个细节，才能造出更强大的轮子。
