JS框架内该如何架构？思考篇

最近写了大图滚动组件，这应该是学JS以来写的第三次了，仍旧不满意，今天偶然看到了迅雷的大图滚动，想到自己写的组件难以应用于此，从构思上就没想到此种情况，顺手写一下想法以作mark。

主要讨论的是实现页面JS特效的JS框架。

目前对组成JS框架的细胞的理解即为：最常用的功能集合。至于这些功能之间如何调用组织则先不考虑。我们写JS框架是为了降低开发成本，最主要的是时间成本。而JS框架要实现的则是：开发者通过定义简单的参数即可获得一个自己想要的效果，最常见的就是new一下，传一个定义了各种参数的对象进去，然后想要的效果就出来了。

这时第一层JS框架功能则出来了，即最外层，与开发者接触最紧密，大家都说的API。这一层做什么做多灵活是JS框架定位的问题，而这一层的功能实现之间如何组织结构、提高代码重用性、提高性能、降低代码量则是第二个思考的问题了。

在写最外层功能中我们总能发现一些常用功能，这些功能提取出来，经过合理的组织协调，就变成了第二层功能组件，这些组件主要是方便开发最外层功能和API而写的。

而最内层的组件，则应该是为第二层功能和第三次组件一起服务的，即一些最基础的功能，比如isArray，isObject，等等。这些功能和原生JS功能十分接近，可以说绝大部分开发场景都可能用到的一些功能。

这三层使用关系如下：（图随便画的，重要的是看关系）

‍

JS框架最外层的组件，需要用到的第二层，也经常会用到核心层。核心层中间很少互相调用，而到第二层中间则往往需要互相调用彼此，来实现一些功能，比如animate可能经常用到dom（这点没在图中画出来）。而到第三层中间则尽量解耦各功能，如图中大图滚动组件不要和弹出层有耦合，但是同时又要保证各功能的可扩展性，至少框架内的各api互相调用要普遍适用。这样做有一个很大的好处，即各功能的拓展性大大提高，而又不需要自己写。如一个大图滚动可能会用到数字导航的tab选项卡效果和滚动图片的lazyLoad效果，如果正常写效果这些就和大图滚动的核心代码耦合到一起，在下次使用时发现要改的很多，还不如重新写。而按照上述思路，则写好tab选项卡和lazyLoad效果，开发者不仅可以单独调用，也可以通过简单的结合，写出效果很炫的大图切换组件。

此次写的大图切换，在一开始没有在第三层解耦，将数字导航和图片滚动写到了一起去，而数字导航仅简单实现了class的切换，但是如迅雷那样的连图片导航都带动画效果的就难以实现。思考之后，大图就是大图，数字导航就是数字导航，虽然从整体效果上看是一个整体，但是从JS框架结构上看，分开更为恰当。分开之后在能出现的场景尽情调用，将开发量适当的转移给框架使用者，反而对整体更好。