电商新平台前端架构说明 - fengliu222/mall-platform GitHub Wiki

模块以页面为单位，按照现在的需求，其实就是每个模块都是一个单独的页面。 模块由编写好的系统组件和没有复用性的模块组件组成。

#####系统组件的概念：

第一种是逻辑组件。它封装了一些通用逻辑，只要将DOM selector作为参数传入构造函数中，所有的事情就都有组件完成。此类组件有如下需要注意的点：

• 需要留出事件接口。通过arale.js的Event库，可以自定义事件。为方便控制组件运行过程中的一些个性需求，需要在一些关键性的地方留出事件接口，这些接口有可能一开始的时候不能准备的太完善，因此可以在开发的过程中不断的重构接口。这样使用组件的人就可以在相应的模块的controller里通过事件去满足个性化需求，而不会影响组件的源码。
• 留出CSS自定义接口。就是说需要通过传入参数的方式制定组件的class，然后在模块的CSS中重置组件样式。这保证了DOM结构和JS重用的情况下，也能满足个性化的需求，做到可以放到任何的页面中。

第二种是参照web components的概念设计的（有自身DOM结构）。它包含了自身所需要的FTL和JS，CSS暂定写到common里。通过后台管理界面的配置，动态的组装到各个模块中。

• 数据应该作为参数传入组件中。组件应该作为一个浏览器标签的拓展，专门负责一种数据的展现形式。无论拿到哪里，展现的样式应该是一样的，而数据是实时供应的。
• 关于组件的引入，可以使用data-*写在HTML标签上，JS加载后自动解析组件名，然后引入组件JS模块，通过JS模块来进行模板的渲染和插入DOM工作。
• 如果基于以上的方式来引入模块，则对模块的文件名和所在文件夹名有一定的约束。可能会在部署的时候出现问题。

#####公共组件： 公共组件的JS可以统一的写在全站都会引入的Common.js下。

#####公共组件和系统组件的区别： 这里有一点，在道具坊项目中，公用组件的JS是写在一个公用的common.js中的。我认为这种写法存在着一种资源浪费，因为并非所有的页面都会引用到写好的公用组件。common.js这种文件，代表这全站都会使用到的东西——比如导航栏，次级导航栏，登录，意见反馈等。

系统组件的例子，如新平台所规划的交叉推荐模块，它可能出现在购买成功页面，也可能出现在某个活动的对话框下面；还有快速充值模块，它也有可能出现在除了首页的其他位置。那么资源的按需加载的优越性就体现出来了。使用的时候只要在标签上加上制定的data，它所需要的HTML，css，和JS就都加载进来了。而不需要去引入一个非常臃肿的common.js.

后台管理界面的「界面设计器」指定了一些模块和数据源之后，当用户访问这个页面时，服务器端会在渲染FTL的时候动态调用模板，并通过macro来传值。服务器端在渲染FTL的时候，会传递进来一个数据模型，转换为JSON大概如下：

  var tempVar ={
     left:{
       rankList:{
          template:"ranklist",
          data:{...}
       }
     }
    right:{
       confirm:{...}
    }
  }

根据如上数据，模板应该这么写:

<div class="left">
  <#list temp.left?keys as key>
     <#assign tname="${temp.left[key].template}">
     <@.vars[tname] tempData=temp.left[key].data />
  </#list>
</div>

上面这段代码保证了所有后台指定的模块都能够填充到页面中，这个页面的布局框架由设计人员事先制定好。   因为一些模块不适合太宽或者不适合太窄的表现，后台管理界面在做模块配置的时候，并非无限制的。如两栏式布局，有些模块应当只允许添加到宽的一栏，一些模块只允许添加到窄的一栏。 

模块逻辑代码无复用性，所以可以直接通过模块的controller层进行控制，模板变量也可以直接写到页面中，无需动态生成。

数据服务负责全站通用的数据接口，所有组件都可以通过数据服务拿到想要的数据，比如区服信息。 数据服务要严格界定边界，不参与逻辑。