产品做到一定程度，JavaScript不仅仅需要几个层面上的重构，而需要将这些合理的、零散的重构集成起来、系统化，最终形成一套适合自己产品的前端框架。

以某套产品的前端框架为例，包含了这么几个组件：

• 1、通用工具组件，提供了UI组件最基础的通用能力，包括：日志、缓存、数据共享、数据异步加载、原生对象扩展、Ajax产品定制化等等。
• 2、共享UI组件，包括：通用弹出框、通用按钮等。
• 3、产品基础模块，在所有页面均加载该JS，包括：评论模块、打分模块、基本资费模块、下载模块、播放模块等等。
• 4、扩展产品模块，仅在特定页面加载该JS，包括：播放器组件、直播频道组件等等。
• 5、关联常量预置模块，这部分主要是一些系统常量无法在JavaScript中确定下来，需要外部传值进去。

（依赖关系：5->1->2->3->4）

上述JS在开发过程中需要细化，并且需要严格限定互相之间的依赖关系，但在发布时，使用脚本或者JS聚合压缩工具整合到特定的一个或几个JS文件中。

?

UI模型和业务模型：

这部分可以说是框架的核心，包括模型的定义和模型数据的存储，所有的接口都是围绕模型制定的。

?

产品框架实施中遇到的几个典型问题：

1、页面JavaScript脚本对于不同语种下需要保持的差异：

譬如阿拉伯语是从右至左排的，那么对于操纵DOM的脚本来说，很可能和英文下有不同的差异，通常语种引起的差异可以用问题抽象和语种归类的办法化解：

比如语言文字从右向左排列和从左向右排列是造成某些展示不同的根本原因，那么在关联常量预置模块中设置好语种，涉及到的语种和左右排列方向的对应关系应当存放在代码中，最后在JavaScript代码中区分对待就可以了。

2、页面上的一些非通用的DOM操纵密切相关的代码和页面展示耦合紧密，这部分代码是不宜置入框架中的，置入后反而不便于产品定制，需要明确这个框架内外的分界线是什么。

3、结合开发团队技能情况制定详细的产品框架实现方案。

比如开发团队成员普遍缺乏JavaScript面向对象能力，这时候就不应当把框架做得太厚，应该对框架外的JavaScript使用适当放宽限制，同时做好命名规约。

4、API接口把关。

需要由有经验的程序员对于框架发布的接口把关，保证接口设计的合理性。

?

文章系本人原创，转载请注明作者和出处