463.com:前端工程之模块化

创建项目结构

在执行创建命令时,Athena会从管理平台下载自定义好的项目模板,可以根据模板创建项目、模块、页面、和组件。Athena有四个创建命令:

通过执行 $ ath app demo 命令就可以生成定义好目录结构的项目。

463.com 1

随后可以通过 $ ath module home来创建一个业务模块;

通过 $ ath page index 来创建页面;

通过 $ ath widget widgetName 来创建组件。

JavaScript 模块

上面我们介绍了一个模板模块是如何定义、调用以及处理依赖的,接下来我们来介绍一下模板模块所依赖的
JavaScript 模块是如何来处理模块交互的。我们可以将任何一段可复用的
JavaScript 代码放到一个 JS 文件中,这样就可以定义为一个 JavaScript
类型的模块,我们无须关心“ define ”闭包的问题,我们可以获得“ CommonJS
”一样的开发体验,下面是 nav.js 中的源码.

// common/widget/nav/nav.js
var $ = require('common:widget/jquery/jquery.js');

exports.init = function() {
    ...
};

我们可以通过 require、require.async 的方式在任何一个地方(包括
html、JavaScript 模块内部)来调用我们需要的 JavaScript 类型模块,require
提供的是一种类似于后端语言的同步调用方式,调用的时候默认所需要的模块都已经加载完成,解决方案会负责完成静态资源的加载。require.async
提供的是一种异步加载方式,主要用来满足“按需加载”的场景,在 require.async
被执行的时候才去加载所需要的模块,当模块加载回来会执行相应的回调函数,语法如下:

// 模块名: 文件所在 widget 中路径
require.async(["common:widget/menu/menu.js"], function( menu ) {
    menu.init();
});

一般 require 用于处理页面首屏所需要的模块,require.async
用于处理首屏外的按需模块。

管理平台

性能优化一直是前端工程师探索的课题,很多时候就是资源的分配问题,也就是资源管理。为了更好地配合本地构建工具来管理资源,我们搭建了管理平台。我们来看下,结合本地构建工具和管理平台,工作流程变成了怎样?

前端模块化带来的性能问题

很多主流的模块化解决方案通过 JavaScript
运行时来支持“匿名闭包”、“依赖分析”和“模块加载”等功能,例如“依赖分析”需要在
JavaScript
运行时通过正则匹配到模块的依赖关系,然后顺着依赖链(也就是顺着模块声明的依赖层层进入,直到没有依赖为止)把所有需要加载的模块按顺序一一加载完毕,当模块很多、依赖关系复杂的情况下会严重影响页面性能。

技术选型

Athena本地工具早期技术选型是 Yeoman + Gulp
的方式,但后来由于安装、更新非常麻烦,命令太长很难打的原因,我们改成了自己开发一个全局安装包的方式,编译核心使用的还是
Gulpvinyl-fs 来实现文件流处理,通过 ES6 Promise
来进行编译流程控制,最小以页面为单位,经过一系列编译任务,最后产出编译好的文件。

463.com 2

模块化基础架构

组件化

在项目中引入组件化的概念,这里的组件对应上文讲到的widget,每一个组件都会包含组件自身的模板、css、js、图片以及说明文件,我们使用组件来拼装页面,像搭积木一样来拼装我们的页面,同时一个组件内可以调用另一个组件。

463.com 3

在拿到设计稿后,我们首先需要确定哪些需要做成公共组件,那些是要做成独立组件,以及组件间如何进行通信。在页面中调用这些组件后,会自动加载组件的模板以及组件的静态资源,而当组件不再需要时,只要移除掉组件引用,那么相应的模板和静态资源也会不再加载。

组件化的好处主要有这么几点

  • 管理方便,我们可以把一个独立功能相关的文件在工程目录中放在一起,这样代码管理起来会非常便利
  • 组件复用,通过抽取公共组件,可以实现组件复用,从而减少工作量,创造价值
  • 分而治之,这是组件化最重要的一点,将页面组件化,就是对页面功能的拆分,将一个大的工程拆成小的零件,我们只需要关注每一个零件的功能,极大地降低了页面的开发与维护的难度

非模块化资源

在实际开发过程中可能存在一些不适合做模块化的静态资源,那么我们依然可以通过声明依赖关系来托管给静态资源管理系统来统一管理和加载,

{require name="home:static/index/index.css" }

如果通过如上语法可以在页面声明对一个非模块化资源的依赖,在页面运行时可以自动加载相关资源。

权限控制

权限控制,项目中存在公共组件模块,公共组件比较稳定,比如说轮播组件、选项卡组件等等,这部分代码一般比较少变动,可由少部分人来更新和维护,所以加入了权限控制机制,保证公共组件的稳定性。

总体架构

为了实现一种自然、便捷、高性能、一体化的模块化方案,我们需要解决以下一些问题,

  • 模块静态资源管理,一般模块总会包含 JavaScript、CSS
    等其他静态资源,需要记录与管理这些静态资源
  • 模块依赖关系处理,模块间存在各种依赖关系,在加载模块的时候需要处理好这些依赖关系
  • 模块加载,在模块初始化之前需要将模块的静态资源以及所依赖的模块加载并准备好
  • 模块沙箱(模块闭包),在 JavaScript
    模块中我们需要自动对模块添加闭包用于解决作用域问题

** 使用编译工具来管理模块 **

我们可以通过编译工具(自动化工具)
对模块进行编译处理,包括对静态资源进行预处理(对 JavaScript
模块添加闭包、对 CSS 进行 LESS
预处理等)、记录每个静态资源的部署路径以及依赖关系并生成资源表(resource
map)。我们可以通过编译工具来托管所有的静态资源,这样可以帮我们解决模块静态资源管理、模块依赖关系、模块沙箱问题。

** 使用静态资源加载框架来加载模块 **

那么如何解决模块加载问题,我们可以通过静态资源加载框架来解决,主要包含前端模块加载框架,用于
JavaScript 模块化支持,控制资源的异步加载。后端模块化框架,用于解决
JavaScript 同步加载、CSS
和模板等模块资源的加载,静态资源加载框架可以用于对页面进行持续的自适应的前端性能优化,自动对页面的不同情况投递不同的资源加载方案,帮助开发者管理静态资源,抹平本地开发到部署上线的性能沟壑。
编译工具和静态资源加载框架的流程图如下:

463.com 4

项目管理

我们在使用本地构建工具时,需要配置多个参数,比如主机信息、选择模版等,在命令行环境下有些不直观。为了简化这个操作,管理平台提供了项目创建的功能,同时提供了模版创建的功能。

463.com 5

在项目信息、模块信息以及组件信息发生变更的时候,为了第一时间能够通知项目成员更新,加入了消息通知的功能,目前通过发送邮件的方式,后期可以加入微信提醒的功能。

JavaScript 模块化并不等于异步模块化

主流的 JavaScript
模块化方案都使用“异步模块定义”的方式,这种方式给开发带来了极大的不便,所有的同步代码都需要修改为异步的方式,我们是否可以在前端开发中使用“
CommonJS
”的方式,开发者可以使用自然、容易理解的模块定义和调用方式,不需要关注模块是否异步,不需要改变开发者的开发行为。

资源管理

资源管理是管理平台的核心,主要分为4个部分:模块展示、依赖关系、组件预览和权限控制。这部分功能主要通过本地构建工具提供的资源关系表来完成。

CSS 模块

在模板模块中以及 JS 模块中对应同名的 CSS 模块会自动与模板模块、JS
模块添加依赖关系,进行加载管理,用户不需要显示进行调用加载。那么如何在一个
CSS 模块中声明对另一个 CSS
模块的依赖关系呢,我们可以通过在注释中的@require
字段标记的依赖关系,这些分析处理对 html 的 style 标签内容同样有效,

/**
 * demo.css
 * @require reset.css
 */
预览时监听细化

在开发进行预览时,会对所有文件的改动进行监听,而针对每一类文件都有非常细化的操作,当文件改动时只会执行改文件所需要的编译任务,而不会进行整体编译,这样可以很好地提升开发效率。例如改动某一组件的CSS文件,则只会针对该文件执行一些相关的CSS操作。

同时得益于所有文件依赖关系的记录,在监听时会根据依赖关系进行文件编译,例如某sass文件中引入了另一个sass库文件,修改这个sass库文件的时候,会根据引用关系表同时更新到所有引用到这个sass文件的文件,这样项目文件更新及时,让开发流程更加流畅。

模块化为打包部署带来的极大不便

传统的模块化方案更多的考虑是如何将代码进行拆分,但是当我们部署上线的时候需要将静态资源进行合并(打包),这个时候会发现困难重重,每个文件里只能有一个模块,因为模块使用的是“匿名定义”,经过一番研究,我们会发现一些解决方案,无论是“
combo 插件”还是“ flush
插件”,都需要我们修改模块化调用的代码,这无疑是雪上加霜,开发者不仅仅需要在本地开发关注模块化的拆分,在调用的时候还需要关注在一个请求里面加载哪些模块比较合适,模块化的初衷是为了提高开发效率、降低维护成本,但我们发现这样的模块化方案实际上并没有降低维护成本,某种程度上来说使得整个项目更加复杂了。

Athena中的API

Athena针对模板提供了一系列的API来扩展丰富的功能,例如前面提到的
<%= widget.load() %> 来实现组件化。

同时Athena中还提供了其他API:

<%= getCSS() %><%= getJS() %>
用来引用CSS/JS文件,传入文件名和模块名;

<%= uri() %>
提供了资源定位功能,可以在模板中标记资源,编译过程中会进行替换,而且在JS中也有资源定位API
__uri()

<%= inline() %>
提供了内联资源的功能,传入文件名和模块名,可以在模板中内联任意资源,例如图片以及JS脚本;而且
inline463.com,
也可以内联一段网络资源,例如线上的JS文件,同样的在JS中也有内联资源API
__inline()

雪碧图标识 ?__sprite ,在CSS中引用图片最后加上标识 ?__sprite
可以自动生成自定义名称雪碧图,同时支持自定义生成多张雪碧图,只需要要标识后面带上一个文件名,就可以生成一张以这个文件名来命名的雪碧图,例如
?__sprite=icons ,这样所有带同样标识的图片就会生成一张以
icons为文件名的雪碧图。

模板模块

我们可以将任何一段可复用的模板代码放到一个 smarty
文件中,这样就可以定义一个模板模块。在 widget 目录下的 smarty
模板(本文仅以 Smarty 模板为例)即为模板模块,例如 common 子系统的
widget/nav/ 目录

├── nav.css
├── nav.js
└── nav.tpl

下 nav.tpl 内容如下:

<nav id="nav" class="navigation" role="navigation">
    <ul>
        <%foreach $data as $doc%>
        <li class="active">
            <a href="#section-{$doc@index}">
                <i class="icon-{$doc.icon} icon-white"></i>{$doc.title}
            </a>
        </li>
        <%/foreach%>
    </ul>
</nav>

然后,我们只需要一行代码就可以调用这个包含 smarty、JS、CSS
资源的模板模块,

// 调用模块的路径为 子系统名称:模板在 widget 目录下的路劲
{widget name="common:widget/nav/nav.tpl" }

这个模板模块(nav)目录下有与模板同名的 JS、CSS
文件,在模板被执行渲染时这些资源会被自动加载。如上所示,定义 template
模块的时候,只需要将 template 所依赖的 JS 模块、CSS
模块存放在同一目录(默认 JavaScript 模块、CSS 模块与 Template
模块同名)下即可,调用者调用 Template
模块只需要写一行代码即可,不需要关注所调用的 template
模块所依赖的静态资源,模板模块会帮助我们自动处理依赖关系以及资源加载。

技术选型

管理平台前端采用React+Redux的方式,后端采用Express+MongoDB,整体技术选型如下:

463.com 6

自适应的性能优化

现在,当我们想对模块进行打包,该如何处理呢,我们首先使用一个 pack
配置项(下面是 fis
的打包配置项),对网站的静态资源进行打包,配置文件大致为,

fis.config.merge({
    pack: {
        'pkg/aio.css': '**.css'
    }
});

我们编译项目看一下产出的 map.json(resource map),有何变化,

{
    "res": {
        "A/A.tpl": {
            "uri": "/template/A.tpl",
            "deps": ["A/A.css"]
        },
        "A/A.css": {
            "uri": "/static/csss/A_7defa41.css",
            "pkg": "p0"
        },
        "B/B.tpl": {
            "uri": "/template/B.tpl",
            "deps": ["B/B.css"]
        },
        "B/B.css": {
            "uri": "/static/csss/B_33c5143.css",
            "pkg": "p0"
        },
        "C/C.tpl": {
            "uri": "/template/C.tpl",
            "deps": ["C/C.css"]
        },
        "C/C.css": {
            "uri": "/static/csss/C_ba59c31.css",
            "pkg": "p0"
        },
    },
    "pkg": {
        "p0": {
            "uri": "/static/pkg/aio_0cb4a19.css",
            "has": ["A/A.css", "B/B.css", "C/C.css"]
        }
    }
}

大家注意到了么,表里多了一张 pkg 表,所有被打包的资源会有一个 pkg 属性
指向该表中的资源,而这个资源,正是我们配置的打包策略。这样静态资源管理系统在表中查找
id 为 A/A.css 的资源,我们发现该资源有 pkg
属性,表明它被备份在了一个打包文件中。

我们使用它的 pkg 属性值 p0 作为 key,在 pkg
表里读取信息,取的这个包的资源路径为 /static/pkg/aio0cb4a19.css_ 存入
uris 数组 中将 p0 包的 has 属性所声明的资源加入到 has 表,在要输出的
html 前面,我们读取 uris 数组 的数据,生成静态资源外链,我们得到最终的
html 结果:

<html>
    <link href="/static/pkg/aio_0cb4a19.css">
    <div>html of A</div>
    <div>html of B</div>
    <div>html of C</div>
</html>

静态资源管理系统可以十分灵活的适应各种性能优化场景,我们还可以统计
{widget}
插件的调用情况,然后自动生成最优的打包配置,让网站可以自适应优化,这样工程师不用关心资源在哪,怎么来的,怎么没的,所有资源定位的事情,都交给静态资源管理系统就好了。静态资源路径都带
md5
戳,这个值只跟内容有关,静态资源服务器从此可以放心开启强缓存了!还能实现静态资源的分级发布,轻松回滚!我们还可以继续研究,比如根据国际化、皮肤,终端等信息约定一种资源路径规范,当后端适配到特定地区、特定机型的访问时,静态资源管理系统帮你送达不同的资源给不同的用户。说到这里,大家应该比较清楚整个“一体化”的模块化解决方案了,有人可能会问,这样做岂不是增加了后端性能开销?对于这个问题,我们实践过的经验是,这非常值得!其实这个后端开销很少,算法非常简单直白,但他所换来的前端工程化水平提高非常大!

提升开发体验

我们主要从以下三个方面来提升我们的开发体验。

前端模块化并不等于 JavaScript 模块化

前端开发相对其他语言来说比较特殊,因为我们实现一个页面功能总是需要
JavaScript、CSS 和 Template 三种语言相互组织才行,如果一个功能仅仅只有
JavaScript 实现了模块化,CSS 和 Template
还是处于原始状态,那我们调用这个功能的时候并不能完全通过模块化的方式,那么这样的模块化方案并不是完整的,所以我们真正需要的是一种可以将
JavaScript、CSS 和 Template 同时都考虑进去的模块化方案,而非仅仅
JavaScript 模块化方案。

依赖关系

依赖关系,主要是html、css、js和图片相互之间的关系。通过分析资源关系依赖表,可以获取到各个资源被引用的情况以及线上版本的情况。当线上环境采用md5来做资源管理时,我们不是很清晰地知道静态资源对应线上哪个版本的资源,而有了这个依赖关系表,当出现问题时,我们可以更快地定位到具体的资源。

463.com 7

静态资源加载框架

下面我们会详细讲解如何加载模块,如下所示,

463.com 8

在流程开始前我们需要准备两个数据结构:

  • uris = [],数组,顺序存放要输出资源的 uri
  • has = {},hash 表,存放已收集的静态资源,防止重复加载
  1. 加载资源表(resource map):

    {
        "res": {
            "A/A.tpl": {
                "uri": "/templates/A.tpl",
                "deps": ["A/A.css"]
            },
            "A/A.css": {
                "uri": "/static/css/A_7defa41.css"
            },
            "B/B.tpl": {
                "uri": "/templates/B.tpl",
                "deps": ["B/B.css"]
            },
            "B/B.css": {
                "uri": "/static/css/B_33c5143.css"
            },
            "C/C.tpl": {
                "uri": "/templates/C.tpl",
                "deps": ["C/C.css"]
            },
            "C/C.css": {
                "uri": "/static/css/C_6a59c31.css"
            }
        }
    }
    
  2. 执行 {widget name=”A”}

    • 在表中查找 id 为 A/A.tpl 的资源,取得它的资源路径
      /template/A.tpl,记为 tplpath,加载并渲染 tplpath
      所指向的模板文件,即 /template/A.tpl,并输出它的 html 内容
    • 查看 A/A.tpl 资源的 deps 属性,发现它依赖资源 A/A.css,在表中查找
      id 为 A/A.css 的资源,取得它的资源路径为
      /static/css/A7defa41.css_,存入 uris 数组 中,并在 has 表
      里标记已加载 A/A.css 资源,我们得到:

      urls = [

      '/static/css/A_7defa41.css'
      

      ];

      has = {

      "A/A.css": true
      

      }

  3. 依次执行 {widget name=”B”}、{widget name=”c”},步骤与上述步骤 3
    相同,得到,

    urls = [
        '/static/css/A_7defa41.css',
        '/static/css/B_33c5143.css',
        '/static/css/C_6a59c31.css'
    ];
    
    has = {
        "A/A.css": true,
        "B/B.css": true,
        "C/C.css": true
    }
    
  4. 在要输出的 html 前面,我们读取 uris
    数组的数据,生成静态资源外链,我们得到最终的 html 结果:

    <html>
        <link rel="stylesheet" href="/static/css/A_7defa41.css">
        <link rel="stylesheet" href="/static/css/B_33c5143.css">
        <link rel="stylesheet" href="/static/css/C_6a59c31.css">
        <div>html of A</div>
        <div>html of B</div>
        <div>html of C</div>
    </html>
    

    上面讲的是对模板和 CSS
    资源的加载,用于描述静态资源加载的流程,下面我们再来详细讲解下对于
    JavaScript 模块的处理,要想在前端实现类似“ commonJS
    ”一样的模块化开发体验需要前端模块化框架和后端模块化框架一起作用来实现,

前端模块化框架,原理上大家可以选择使用 requireJS 或 SeaJS
来作为模块化支持,但是我们并不建议这么做,我们建议大家使用一个 mininal
AMD API,例如 requireJS 的 almond 版本或者其他的精简版本,requireJS
完整版有 2000 余行,而精简版模块化框架只需要 100
行代码左右就可以实现,只需要实现以下功能:

  • 模块定义,只需要实现如下接口 define (id, factory),因为 define
    闭包是工具生成,所以我们不需要考虑匿名闭包的实现,同时也不需要考虑“依赖前置”的支持,我们只需要支持一种最简单直接的模块化定义即可
  • 模块同步调用,require (id),静态资源管理系统会保证所需的模块都已预先加载,因此
    require 可以立即返回该模块
  • 模块异步调用,考虑到有些模块无需再启动时载入,因此我们需要提供一个可以在运行时加载模块的接口
    require.async (names, callback),names 可以是一个
    id,或者是数组形式的 id 列表。当所有都加载都完成时,callback
    被调用,names 对应的模块实例将依次传入。
  • 模块自执行,即 AMD 规范的提前执行,之所选择这样做的原因是考虑到
    Template 模块的特殊性,一般 Template 模块都会依赖 JavaScript
    模块来做初始化工作,选择模块自执行的方式我们就不需要显式的在
    Template 页面上书写 require 依赖,静态资源系统会自动加载 Template
    模块的依赖,当模块并行加载结束后会一次自执行。大家可能会认为如果页面存在一些用不到的模块那都自执行岂不会浪费资源,这里大家可以不用担心,静态资源系统投放到前端的模块都是页面初始化所需要的,不存在浪费资源的情况。
  • Resource map 前端支持,主要用于为异步模块调用提供 uri
    支持,resourceMap
    为静态资源管理系统自动生成,无需人工调用,用于查询一个异步模块的真正
    url,用于自动处理异步模块的
    CDN、资源打包合并、强缓存问题,格式如下,

    require.resourceMap({
        "res": {
            "common:widget/sidebar/sidebar.async.js": {
                "url": "/static/common/widget/sidebar/sidebar.async_449e169.js"
            }
        }
    });
    
  • 处理循环引用,参照 nodeJS 处理循环引用的方式,在造成循环依赖的
    require 之前把需要的东西 exports 出去,例如

    // a.js
    console.log('a string');
    exports.done = false;
    var b = require('./b.js');
    console.log('in a, b.done = ' + b.done);
    exorts.done = true;
    console.log('b done');
    
    // b.js
    console.log('b starting');
    exports.done = false;
    
    var a = require('./a.js');
    console.log('in b, a.done = ' + a.done);
    exports.done = true;
    console.log('b done');
    
    // main.js
    console.log('main starting');
    var a = require('./a.js');
    var b = require('./b.js');
    console.log('in main. a.done = ' + a.done + ', b.done = ' + b.done);
    

    如果在加载 a 的过程中,有其他的代码(假设为 b)require a.js
    的话,那么 b 可以从 cache 中直接取到 a 的
    module,从而不会引起重复加载的死循环。但带来的代价就是在 load
    过程中,b 看到的是不完整的 a。

后端模块加载框架,主要用于处理模块的依赖并生成模块静态资源外链,下面我们将以实例讲解静态资源管理系统是如何对
JavaScript 模块进行加载的,如下我们有一个 sidebar 模块,目录下有如下资源

├── sidebar.async.js
├── sidebar.css
├── sidebar.js
└── sidebar.tpl

sidebar.tpl 中的内容如下,

<a id="btn-navbar" class="btn-navbar">



</a>

{script}
    $('a.btn-navbar').click(function() {
        require.async('./sidebar.async.js', function( sidebar ) {
            sidebar.run();
        });
    });
{/script}

对项目编译后,自动化工具会分析模块的依赖关系,并生成 map.json,如下

"common:widget/sidebar/sidebar.tpl": {
    "uri": "common/widget/sidebsr/sidebar.tpl",
    "type": "tpl",
    "extras": {
        "async": [
            "common:widget/sidebar/sidebar.async.js"
        ]
    },
    "deps": [
        "common:widget/sidebar/sidebar.js",
        "common:widget/sidebar/sidebar.css"
    ]
}

在 sidebar 模块被调用后,静态资源管理系统通过查询 map.json
可以得知,当前 sidebar 模块同步依赖 sidebar.js、sidebar.css,异步依赖
sdebar.async.js,在要输出的 html 前面,我们读取 uris
数组的数据,生成静态资源外链,我们得到最终的 html

<script type="text/javascript">
    require.resourceMap({
        "res": {
            "common:widget/sidebar/sidebar.async.js": {
                "url": "/satic/common/widget/sidebar/sidebar.async_449e169.js"
            }
        }
    });
</script>
<script type="text/javascript" src="/static/common/widget/sidebar/sidebar_$12cd4.js"></script>

如上可见,后端模块化框架将同步模块的 script url 统一生成到页面底部,将
css url 统一生成在 head 中,对于异步模块(require.async)注册 resourceMap
代码,框架会通过{script}标签收集到页面所有 script,统一管理并按顺序输出
script 到相应位置。

编译缓存

在图片压缩和sass编译时,开启文件缓存,将已经编译过且没有改动的文件过滤掉,不再编译,大幅提升编译速度。

模块化是一种处理复杂系统分解成为更好的可管理模块的方式,它可以把系统代码划分为一系列职责单一,高度解耦且可替换的模块,系统中某一部分的变化将如何影响其它部分就会变得显而易见,系统的可维护性更加简单易得。

按需加载

同时,我们考虑通过尽量减小页面体积来提升页面打开速度,在业务上我们将页面划分为一个个楼层组件,以京东美妆馆为例,页面中从上而下分为首焦、至IN尖货、今日特惠、潮流前沿、口碑榜单这么几个楼层组件,其实这个页面还有很长,内容非常多且复杂。

463.com 9

之前我们的做法是整个页面直出,这样一次性加载的内容会非常多,为了提升打开速度,我们考虑通过按需加载的方式来优化页面的加载。我们在页面中只放每一个楼层的框架性代码,楼层的模板和数据都通过异步的方式去拉取,来实现楼层组件的按需加载,同时我们可以对模板以及数据进行缓存,以此来减少请求,做更极致的优化。在开发中我们以正常组件的方式去开发整个页面,随后通过编译工具,在代码编译阶段自动将楼层的模板抽离成一个独立的JS文件,并给楼层容器打上标记位,通过页面加载逻辑去按需拉取模板,再进行渲染。

通过给楼层容器和模板分别加上标记位 o2-out-tpl-wrapper o2-out-tpl

463.com 10

在编译时自动将指定的模板代码抽离成独立js文件

463.com 11

并且给楼层容器打上标记

463.com 12

同时在逻辑脚本适当位置自动加入模板的版本

463.com 13

通过上述步骤,实现按需加载的自动化生成,在提升性能的同时,很好地解放我们生产力。

编译工具

自动化工具会扫描目录下的模块进行编译处理并输出产出文件:

静态资源,经过编译处理过的 JavaScript、CSS、Image 等文件,部署在 CDN
服务器自动添加闭包,我们希望工程师在开发 JavaScript
模块的时候不需要关心” define
”闭包的事情,所以采用工具自动帮工程师添加闭包支持,例如如上定义的 nav.js
模块在经过自动化工具处理后变成如下,

define('common:widget/nav/nav.js', function( require, exports, module ) {
    // common/widget/nav/nav.js
    var $ = require('common:widget/jquery/jquery.js');

    exports.init = function() {
        ...
    };
});

模板文件,经过编译处理过的 smarty 文件,自动部署在模板服务器

资源表,记录每个静态资源的部署路径以及依赖关系,用于静态资源加载框架
静态资源加载框架(SR Management System)会加载 source maps
拿到页面所需要的所有模块以及静态资源的 url,然后组织资源输出最终页面。

写在最后

本次分享首先讲述了我们在业务膨胀、人员不断增加的背景下遇到的项目开发上的问题,并提出了我们自己对于这些问题思考总结后得出的解决方案与思路,最后产出适合我们团队、业务的开发工具——
Athena。希望我们的方案能给大家带来一定的借鉴作用。

1 赞 14 收藏
评论

463.com 14

一体化的前端模块化实践方案

写到这里,其实我们的“前端工程之块化”才正式开始,本文面向对前端模块化开发有所实践或有所研究的同学,接下来我们所介绍的前端模块化解决方案,
有别于 JavaScript 模块化方案或 CSS
模块化方案,它是一种可以综合处理前端各种资源的模块化方案;它可以极大提升开发者的开发体验,并为性能优化提供良好的支持。下面让我们来进一步来了解什么是“一体化”的模块化实践方案。

首先我们来看一下一个 web
项目是如何通过“一体化”的模块化方案来划分目录结构:

463.com 15

  • 站点(site):一般指能独立提供服务,具有单独二级域名的产品线。如旅游产品线或者特大站点的子站点(lv.baidu.com)。
  • 子系统(module):具有较清晰业务逻辑关系的功能业务集合,一般也叫系统子模块,多个子系统构成一个站点。子系统(module)包括两类:
    common 子系统,
    为其他业务子系统提供规范、资源复用的通用模块;业务子系统:,根据业务、URI
    等将站点进行划分的子系统站点。
  • 页面(page): 具有独立 URL 的输出内容,多个页面一般可组成子系统。
  • 模块(widget):能独立提供功能且能够复用的模块化代码,根据复用的方式不同分为
    Template 模块、JS 模块、CSS 模块三种类型。
  • 静态资源(static):非模块化资源目录,包括模板页面引用的静态资源和其他静态资源(favicon,crossdomain.xml
    等)。

前端模块(widget),是能独立提供功能且能够复用的模块化代码,根据复用的方式不同分为
Template 模块、JS 模块、CSS 模块三种类型,CSS 组件,一般来说,CSS
模块是最简单的模块,它只涉及 CSS 代码与 HTML 代码; JS
模块,稍为复杂,涉及 JS 代码,CSS 代码和 HTML 代码。一般,JS
组件可以封装 CSS 组件的代码; Template 模块,涉及代码最多,可以综合处理
HTML、JavaScript、CSS 等各种模块化资源,一般情况,Template 会将 JS
资源封装成私有 JS 模块、CSS 资源封装成自己的私有 CSS
模块。下面我们来一一介绍这几种模块的模块化方案。

存在的问题

在平常的开发中,经常需要前后端联调,但是在项目开始之初,很多接口并没有提供,在以前的开发模式下,需要等待后端提供接口或者自己先定义接口,前端开发的进度可能会受影响。

前端开发领域(JavaScript、CSS、Template)并没有为开发者们提供以一种简洁、有条理地的方式来管理模块的方法。CommonJS(致力于设计、规划并标准化
JavaScript API)的诞生开启了“ JavaScript 模块化的时代”。CommonJS
的模块提案为在服务器端的 JavaScript
模块化做出了很大的贡献,但是在浏览器下的 JavaScript
模块应用很有限。随之而来又诞生了其它前端领域的模块化方案,像
requireJS、SeaJS 等,然而这些模块化方案并不是十分适用
,并没有从根本上解决模块化的问题。

工作流程

  1. 在管理平台上创建项目,输入项目名称和预览机,以及选择相应的模板等;
  2. 在终端执行ath
    app指令,工具会优先拉取远程服务器的项目信息来初始化项目,如果没有获取到相关信息,就会在本地生成项目,并将项目信息上报给服务器;
  3. 项目初始化后,就可以创建模块、页面、组件了;
  4. 在编码过程中,可通过ath server预览页面;
  5. 在本地通过后,可执行ath publish将代码发布到开发机或者预览机。

在上面的publish指令中,工具会扫描所有文件,执行代码检查,扫描页面文件,获取组件依赖关系,根据组件依赖关系进行文件合并,然后会进行样式处理、js处理以及图片的处理,根据配置是否进行md5重命名文件,组装html,插入样式、js和图片,最后将编译好的文件发布到相应的机器。在整个过程里面,会生成资源关系依赖表,最终会将资源关系表及编译后的文件上传至管理平台。

除此之外,每个指令的操作都会上报给管理平台。管理平台收到数据后,会对数据进行处理,最终可以在平台上看到项目相关的信息。

整体工作流程图如下:

463.com 16

从上面的工作流程中,我们可以看到,管理平台需要有数据统计、资源管理以及项目管理的功能。整体架构图如下:

463.com 17

项目实例

下面我们来看一下在一个实际项目中,如果在通过页面来调用各种类型的
widget,首先是目录结构:

├── common
│   ├── fis-conf.js
│   ├── page
│   ├── plugin
│   ├── static
│   └── widget
└── photo
    ├── fis-conf.js
    ├── output
    ├── page
    ├── static
    ├── test
    └── widget

我们有两个子系统,一个 common 子系统(用作通用),一个业务子系统,page
目录用来存放页面,widget 目录用来存放各种类型的模块,static
用于存放非模块化的静态资源,首先我们来看一下 photo/page/index.tpl
页面的源码,

{extends file="common/page/layout/layout.tpl"}
{block name="main"}
    {require name="photo:static/index/index.css"}
    {require name="photo:static/index/index.js"}
    <h3>demo 1</h3>
    <button id="btn">Button</button>
    {script type="text/javascript"}
        // 同步调用 jquery
        var $ = require('common:widget/jquery/jquery.js');

        $('#btn').click(function() {
            // 异步调用 respClick 模块
            require.async(['/widget/ui/respClick/respClick.js'], function() {
                respClick.hello();
            });
        });
    {/script}

    // 调用 renderBox 模块
    {widget name="photo:widget/renderBox/renderBox.tpl"}
{/block}

第一处代码是对非模块化资源的调用方式;第二处是用 require 的方式调用一个
JavaScript 模块;第三处是通过 require.async 通过异步的方式来调用一个
JavaScript 模块;最后一处是通过 widget 语法来调用一个模板模块。 respclick
模块的源码如下:

exports.hello = function() {
    alert('hello world');
};

renderBox 模板模块的目录结构如下:

└── widget
    └── renderBox
        ├── renderBox.css
        ├── renderBox.js
        ├── renderBox.tpl
        └── shell.jpeg

虽然 renderBox 下面包括 renderBox.js、renderBox.js、renderBox.tpl
等多种模块,我们再调用的时候只需要一行代码就可以了,并不需要关注内部的依赖,以及各种模块的初始化问题。

首屏优化

页面的打开速度一直是大家非常关心的一个指标,一个页面打开太慢会让让用户失去等待的耐心,为了让用户更快地看到页面,我们考虑将页面中部分静态资源代码直接嵌入页面中,我们通过工具处理,在工程编译阶段,将指定的静态资源代码内嵌入页面中,这样可以减少HTTP请求,提升首屏加载速度,同时降低页面裸奔风险。

总结

本文是 fis
前端工程系列文章中的一部分,其实在前端开发工程管理领域还有很多细节值得探索和挖掘,提升前端团队生产力水平并不是一句空话,它需要我们能对前端开发及代码运行有更深刻的认识,对性能优化原则有更细致的分析与研究。fis
团队一直致力于从架构而非经验的角度实现性能优化原则,解决前端工程师开发、调试、部署中遇到的工程问题,提供组件化框架,提高代码复用率,提供开发工具集,提升工程师的开发效率。在前端工业化开发的所有环节均有可节省的人力成本,这些成本非常可观,相信现在很多大型互联网公司也都有了这样的共识。

本文只是将这个领域中很小的一部分知识的展开讨论,抛砖引玉,希望能为业界相关领域的工作者提供一些不一样的思路。欢迎关注fis项目,对本文有任何意见或建议都可以在fis开源项目中进行反馈和讨论。

作者:walter
(http://weibo.com/u/1916384703)
 – F.I.S 

本地预览

执行预览命令 $ath serve
会执行精简版编译任务来编译项目,编译完项目后会生成一份站点地图,随后打开一个本地服务器来预览项目,使用这个命令可以很方便地进行开发,在预览时会同时watch目录和文件的改动,并且提供了livereload功能,我们可以在预览时任意修改文件,都将实时地反映到页面中,同时可以新建另一个窗口执行新增组件和页面的操作,让整个开发过程非常顺畅,我们只需关注开发本身就好,不需要再关注其他事。

463.com 18

执行完编译任务后,默认自动打开浏览器,预览站点地图

463.com 19

组件提交到组件平台

通过ath
widget-publish指令将组件提交到组件平台,组件平台会对组件源码进行编译,将组件名称md5、组件归类以及组件版本记录等等。

463.com 20

自身优化

为了提升开发效率,Athena做了一些优化操作

从组件平台上下载组件

通过ath
widget-load指令将组件下载到本地,当本地构建工具向组件平台发起请求时,会带上组件名称,组件平台会将源码进行编译,将组件名称重命名,并且相应地替换源码中的组件名称,同时记录组件的被引用记录。

463.com 21

相关文章