糯米PC端重构之实践糯米PC端重构之实践

上一篇文章谈到了重构的原因和基本思路，在这片文章里我们将具体地阐述我们是如何做的。
技术选型基本采用了原有的技术实现，以js、less和html为基础，这没什么好说的。在服务端模板的选择中，我们选择了smarty模板，在糯米的wap端，我们采用了crox这个模板，两者我们都解决了同一份模板在前后端通用的小难题，大大地提高了开发效率。
目录结构我们的目录结构参考了我们的团队规范，抛弃了原有的FIS的结构形式，变为以下形式：

. ├── bower.json ├── build ├── build.sh ├── dep // 第三方依赖 ├── fis-conf.js ├── gulpfile.js ├── mock ├── node_modules ├── package.json ├── preview ├── src ├── static // 静态资源 ├── template // 后端模板 ├── test ├── tool └── webpack.config.js

模块管理我们的模块构建方式采用commonjs，因此我们可以利用npm上大量的优质模块，通过webpack可以跟我们前端开发常用的AMD和CMD无缝的结合。
第三方依赖开发过程中，必不可少将会用到社区里现有的优质模块，通过bower进行所有模块的管理，我们将统一放在dep文件夹下进行管理，并通过webpack的配置，可以在本地模块的应用。如在webpack的reslove配置项中配置相应的alias，就可以在实际开发中调用它，如requirejs的path配置。

// webpack.config.js alias = { 'moye': depPath + '/moye/src/ui', 'avalon': depPath + '/avalon/dist/avalon', 'etpl': depPath + '/etpl/src/main' }; // main.js var moye = require('moye'); var avalon = require('avalon');

管理其他资源开发过程中，一个组件通常包含多种资源（图片、less、swf、tpl等），如何才能方便的调用和管理呢？
对于以上问题，通过webpack的loader机制，我们将所有的资源都统一在JS中进行管理，而且我们可以通过编写自己的loader，来实现自己的所需的资源加载机制。举个栗子，

require('./main.less'); // 组件所需的less var etpl = require('etpl'); // 前端模板引擎 var search = require('./search/main'); // js var suggestion = require('raw!./suggestion.html'); // html文本，前端模板引擎用 var smartyTpl = require('smarty4js!./smarty.tpl'); // smarty模板，转成js模板函数 var $ = require('jquery'); var exports = { init: function (options) { // do something }, render: function () { // data是数据对象 etpl.compile(suggestion).render(data); smartyTpl.render(data); } }; module.exports = exports;

通过上面的代码实例，我们发现所有的资源都在一个main.js获得清晰的展现，而不是分散在整个项目中，因此便于更好地维护一个组件，组件在一定程度上变得内聚。通过webpack的loader，我们将一些需要通过手动或者命令行方式的工作，直接通过代码就能实现。
前端测试测试采用了karma + jasmine 结合完成，因为我们的运行代码是通过webpack打包器生成的，所以测试过程中需要karma与webpack相结合。
上线部署在上线部署中，我们保留原有的FIS的部署功能，利用FIS强大的工程化的功能，我们的将资源路径替换、发布到测试机器、压缩打包、strong text、资源统计追踪等繁琐的工作全部以工程化的形式完成，大大的节约了人力成本，有兴趣可以参考FIS官网的示例。
构建工具将一系列工作我们通过gulp全部串联起来，整个过程所需要的命令为数不多。我们所用的gulp文件如下：

var gulp = require('gulp'); var config = require('./webpack.config'); var webpack = require('gulp-webpack-build'); var shelljs = require('shelljs'); var path = require('path'); var fs = require('fs'); var cwd = process.cwd(); var etpl = require('etpl'); var karma = require('karma').server; // clean all files gulp.task('clean', function () { shelljs.rm('-rf', path.join(cwd, 'static','common')); shelljs.rm('-rf', path.join(cwd, 'static','car')); }); function printResult(stats) { stats = stats.toJson(); (stats.errors || []).forEach(function (err) { console.error('error', err); }); stats.assets.forEach(function (item) { var size = (item.size / 1024.0).toFixed(2) + 'kB'; console.log('generated', item.name, size); }); }var src = 'https://www.it610.com/article/src', webpackOptions = { debug: false, // devtool: '#source-map', watchDelay: 200 }, webpackConfig = { useMemoryFs: true, progress: true }; var CONFIG_FILENAME = './webpack.config.js'; var dest = './static'; gulp.task('webpack', [], function() { return gulp.src('./webpack.config.js', { base: path.resolve(src) }) .pipe(webpack.init(webpackConfig)) .pipe(webpack.props(webpackOptions)) .pipe(webpack.run()) .pipe(webpack.format({ version: false, timings: true })) .pipe(webpack.failAfter({ errors: true, warnings: true })) .pipe(gulp.dest(dest)); }); gulp.task('build', function () { gulp.src('./src/**/*.tpl') .pipe(gulp.dest('template/newpc')); }); gulp.task('watch', function () { gulp.watch(['./src/**/*.js', './src/**/*.less']).on('change', function(event) { if (event.type === 'changed') { gulp.src(event.path, { base: path.resolve(src) }) .pipe(webpack.closest(CONFIG_FILENAME)) .pipe(webpack.init(config)) .pipe(webpack.props(webpackOptions)) .pipe(webpack.watch(function(err, stats) { gulp.src(this.path, { base: this.base }) .pipe(webpack.proxy(err, stats)) .pipe(webpack.format({ verbose: true, version: false })) .pipe(gulp.dest(dest)); })); } }); }); gulp.task('test', function (done) { karma.start({ configFile: __dirname + '/test/config.js' }, done); }); gulp.task('debug', ['webpack'],function(){ var process = require('child_process'); process.exec('fis release -d local'); });

后续规划现如今糯米PC的技术框架还是采用以jquery为基础的模块化前端框架，这次通过commonjs的组织方式，也是为了后面代码能够在Node等后端进行处理，更好地达到前后端分层开发，完完全全去除后端模板的依赖。
【糯米PC端重构之实践】在思考的过程中，实际是借鉴React，希望后续在浏览器兼容放开的基础和React更加成熟的基础上，糯米部分复杂的业务能采用React Component的方式进行开发，来实现同构开发。