关于新框架的使用体会

       此次通过一个新增模块的业务，尝试了用全新的方式去实现。个中波折感悟，以下一 一表述。

       总的来说，新框架的核心思路还是模块化，架构上通过目录结构的形式，利用RequireJs，业务逻辑和通用模块的设计上去做到模块的独立性，降低模块间的耦合。模块化一直也是我们最近前端架构调整的一个方向，新旧对比而言，在模块化的思路上我感觉主要有以下几个区别：

旧：
      1，模块划分上，主要以大的功能区块来划分，模块的体量比较大，通常会包含几个页面；
      2，模块内没有或较少再去细分模块，导致模块内部的公用css、img、js方法等复用度参差不齐；
      3，优点是目录相对精简，大模块内部的结构符合习惯的目录放置方式，理解上没有门槛，可以快速在团队中形成规范；

新：
      1，模块划分上，视觉上通过页面小模块为单位来划分；业务逻辑上，结合视觉模块，通过base模块/全局业务模块/部分通用模块/单模块来划分；
      2，划分上层级明晰，在大模块的划分内部有小模块的划分，通过requireJs来解决依赖加载和明确模块间的关系；
      3，模块划分单位较小，导致模块会较多，此时处理目录结构可以改进；模块内部html，css，js的引入应该更具模块化的思路，让模块内部各文件联系更紧密。

       下面主要就新框架的思路以及具体做法来展开说明一下。

一，模块划分及目录结构

我们以自助报修和24小时托管的蒙层来说明模块划分的思路。

两个页面的蒙层相似度很高

       显而易见的，两个页面的蒙层的共同特征决定了他们应该是一个模块，不管是页面样式，还是底部按钮的js，还是数字动画，都是一样的。所以，蒙层应该是独立出一个模块，然后两个页面的蒙层来继承这个蒙层模块的样式与js方法；目录结构如下：

模块划分的目录结构示例

        在文件放置位置上，通过页面名称来放置同一页面的不同模块。如报修页Maintenance下，有三个不同模块，蒙层模块，报修弹窗模块，报修原因弹窗模块，表明了这三个模块的作用页面；如此具体模块的页面结构关系便清晰了；
       在文件命名规则上，通过命名来表明模块的继承关系，如Hour24文件夹下的 H24Matte，通过后半部分单词来表明其继承的模块的名字；如此，模块的功能上的从属关系也会很明确；

二，模块继承的具体实现

        我们还是以蒙层为例，分别来说css和js的复用与继承；
1，CSS
        当前H24Matte和报修蒙层RepairMatte的公用样式文件就是Matte模块下的main.css，引入方式依旧是如以往的方式----放置于global.css中，全局引用；我认为当前的方式有两方面的弊端：其一，只是两个蒙层的公用样式，放置于全局的css中一并压缩，很多不需要用到这些css的页面也引入了这些代码，增加了css的代码量，影响性能，也增加了样式覆盖、相互影响的风险（当然我们有做防覆盖的措施，可以杜绝）；其二，公用放全局，没有实现模块的高移植、快速复用的特性；如果不放在global中全局引用，而是通过页面标签的方式引入，这样也无疑增加了模块复用的麻烦；因为你必须要记得给你继承模块的每个页面去添加一行link引入。
        我认为，要实现模块css的快速移植复用，不应该去过多考虑我继承的模块的公共css在哪儿引入；而应该通过继承的js方法动态的将公共的css插入到所继承的页面模块中；如此，只需要在模块的公共js写一个公共的插入css的方法即可；

2，JS
        H24Matte和报修蒙层RepairMatte的公用js文件就是Matte模块下的main.js，引入方式不同以往。如下所示：

公共蒙层模块的js

继承了公共蒙层模块的24小时托管蒙层模块；

        通过这种依赖关系，就实现了js内部方法的继承，requireJs会根据依赖模块自动去请求js文件，所以我们不需要将Matte/main.js通过