一个前端工程师,机器学习和前端有关的实践会有哪些

基于ES6,使用React、Webpack、Babel构建模块化JavaScript应用
发表于 19:42|
来源medium|
作者Tim Ermilov
摘要:如何基于ES6,使用React构建一个新JavaScript应用?如何将ES6代码发布到NPM上?又如何在后续项目中使用这些代码?……本文通过具体的编程实践,一一揭晓。
【编者按】本文为《》的简译内容,讲述了作者基于ES6,使用React、Webpack、Babel构建模块化JavaScript应用的编程心得。如果你想用React构建一个新的JavaScript应用,而且你还想实践ES6语法中的新特性,此外,你甚至想创建一些可重用组件并发布到NPM上,那么你究竟应该怎样实现这些需求?你如何将ES6代码发布到NPM,又如何在后续的项目中使用这些代码?我花了一些时间解决上面这些问题,现在我愿意与你们分享我习得的新知识。
如果你真的不希望阅读所有的细节,只想看看代码最终的效果——可以直接阅读最后一部分。
我们先来搞清楚我们到底想要得到什么,应该如何去实现。
我们的主要目标是:基于ES6,使用我们自定义的React组件创建一个React应用。其中最棘手的部分是自定义React组件。以下是实现这些目标的需求列表:
自定义组件应该使用ES6编写;
自定义组件应该完全自给自足(使用方法足够简单:安装,导入,渲染);
自定义组件应该提供自身所需的样式(参考第2条,自给自足);
自定义组件应该通过安装(因为);
最后——所有自定义组件应该有单元测试和代码覆盖率报告;
加分项——自定义组件不应该相互依赖,但是应该能够相互影响。
此外,我们需要一些很棒的调试工具,例如:代码检查、源码映射(因为代码需要编译,所以这是调试的必要工具)。
现在我们已了解所有需求,可以开始寻找满足这些需求的方法。所以,首先需要选定我们将使用的工具集和相关库。
我们要基于ES6开发应用,目前的,所以我们需要将ES6编译为ES5。同时我们希望通过NPM管理自定义组件,需要选用一个兼容CommonJS的工具集。
目前有两种流行的可用选择——和。二者都满足我们的大部分需求,考虑到我们的项目需要使用样式文件,而Webpack对非JavaScript文件(例如:样式文件、图片、字体文件)非常友好,所以最终我们将选用Webpack。
Webpack已经能够满足大部分需求,我们将在此基础上加入,帮助我们完成更多任务(例如:单元测试、代码覆盖率检测、静态资源伺服)。
现在我们已经知道如何使用Webpack和Gulp.js来构建代码,可是如何才能满足我们的第一个需求——使用ES6?我们可以使用转译器,帮助我们将ES6代码转译为主流浏览器支持的ES5代码。目前流行的转译器有:、、(勉强算是),我们将选用Babel.js,它有一个更好的生态系统(插件、扩展等)。如果你尚不知晓其为何物,请记住这是一个非常棒的项目,我推荐你阅读它们的文档。最棒的是,Babel.js不仅支持ES6语法,它还可以编译JSX,所以我们可以在编译步骤彻底弃用标准React
JSX编译器了!
如果你只想使用Babel.js,我推荐你阅读它们的。Axel Rauschmayer博士曾经撰写,也值得一读,如果你对JavaScript感兴趣,我也极力推荐订阅他的博客。
现在我们选定了ES6转译器,让我们讨论一下自给自足的问题。如果我们开发纯React组件——那么可以轻松地让它们独立工作(可重用),你甚至可以参考学习编码方式。但如果我们需要在组件内提供默认的自身样式,需要怎样实现呢?
当然,我们可以选择“纯JS”方法向我们的JSX文件加入内联样式,就像这样:
const render = function() {
const defaultStyle = {
color: 'red',
&div style={defaultStyle}&
I have inline styles
JSX内联样式
这个方法存在一个问题,我们几乎无法通过父应用控制这个组件的样式。而且,如果我们需要加载图片或自定义字体文件,这个方法就会失效。所以,是否有更好的方法呢?
Webpack可以帮你解决这个问题!幸运的是,Webpack 加载器可以加载许多类型的文件。其背后的思想非常简单——在加载过程中动态地对载入文件进行可插拔转换。从本质上来说,加载器为我们处理各种文件。我们将选用一个特殊的来将我们的ES6代码转译为ES5代码。
但最酷的是,加载器可以处理任何文件。所以,如果我们想加载样式——我们只需要添加style-loader!最终,我决定使用LESS,它稍微复杂一些——我将创建如下的加载链:
首先,使用处理*.less文件,将其转换为CSS;
然后,使用将编译好的css传递给下一个步骤;
最后,使用将最终的样式引入到生成的代码中。
通过这个加载链,我们可以使用LESS编写组件的样式,下面这段代码演示了这种组件的入口点:
import './style/style.less';
import Component from './src/component';
export default C
借助Webpack将样式引入到JavaScript中&
正如你所见,加载样式像导入文件一样简单。的确,由less-loader、css-loader以及style-loader构成的加载链必须要在我们的Webpack配置文件中提前配置好(参考下一节的第一个示例)。
现在我们可以从相互独立的组件中加载样式,但是CSS默认使用全局变量,这意味着如果两个组件中使用了相同的类名,其中一个将被改写,我们如何回避这个问题呢?
我能想出来的最简单的方法是:在HTML标签和样式文件中,使用组件名称作为最外层元素的类名,人为地创建组件的作用域。就像这样:
.component-name {
const render = function() {
&div className="component-name"&
&span&I have scoped styles&/span&
组件样式的人为作用域
如此一来,所有组件将拥有唯一命名,当他们被封装进同一个应用中时不再产生冲突,能够很好地协同工作。而且,当我们想在应用层重新定义组件样式时,可以使用组件命名作为类名直接改写。
接着,你如何将ES6模块发布到NPM上呢?事实上,你无须这样做。至少目前还不需要。你可以直接向外发布你的原生代码,但这通常是一个糟糕的想法,当你后续想将代码引入到主应用或其它组件中时会感到非常痛苦。当然,你可以通知Webpack(同样也可以通知Browserify)来编译需要用到的代码。但是,如果这样做,你不得不使用Webpack(以及浏览器)来运行各种测试,我通常在命令行中运行测试,因为这样运行速度更快,并且便于后续的自动化测试封装(也就是我们常说的持续集成)。
目前我在项目中应用的最好方法是——同时传送原生ES6代码和编译后的ES5代码,实现这个方法非常简单:
向你的package.json文件添加构建指令;
在预发布阶段运行构建指令;
使用编译后的ES5代码作为主文件;
通过package.json文件的额外字段暴露ES6代码。
它看起来是这样的:
"name": "es6-component",
"version": "1.0.0",
"description": "My awesome ES6 component",
"main": "es5/component.js",
"es6": "index.js",
"scripts": {
"build": "gulp build",
"prepublish": "npm run build"
将ES6模块发布到NPM上的package.json
这种方法有两个优点:
在所有ES5代码中,我们可以轻松地引入或require()这个模块,它能够正常工作!
如果我们出于某些原因需要用到模块的源代码,我们同样可以轻松地通知Webpack使用“ES6”字段来加载或引入ES6代码。
单元测试及代码覆盖率
你必须佩服的是,在Babel中配置单元测试和代码覆盖率检测非常简单(得益于Babel伟大的生态系统,正如我之前提到的那样)。
--compilers: jsx?:babel/register
我一直使用作为测试工具,所以我会讲解如何将其应用到项目中。支持ES6代码非常简单,你只需在执行mocha指令时添加一个编译flag(或添加到mocha配置文件)就可以通知mocha使用babel预编译器:
完成这一步之后,就可以在ES6代码中运行测试了,当然你也可以使用ES6来编写测试文件!
现在要处理最棘手的部分——我们有了React组件,我们想使用mocha完成测试,却又不想在浏览器中运行测试(可以运行一个,但是它非常繁重),我们应该如何去做呢?
答案就是——基于用JavaScript实现了WHATWG的DOM和HTML标准。它比Phantom更轻量,并且满足几乎所有我们测试React所需的功能。
以下是为React配置jsdom环境的测试helper文件的示例:
import localStorage from 'localStorage';
import {jsdom} from 'jsdom';
// init jsdom
global.document = jsdom();
global.window = global.document.defaultV
global.navigator = global.window.
// local storage polyfill
global.window.localStorage = localS
global.localStorage = localS
// import react after dom
const React = require('react/addons');
before(function() {
// expose react and testutils
this.React = R
this.TestUtils = React.addons.TestU
beforeEach(function() {
// create container
this.container = global.window.document.createElement('div');
afterEach(function(done) {
// clean jsdom
this.React.unmountComponentAtNode(this.container);
// timeout
setTimeout(done);
在命令行中运行React测试的jsdom环境
注意我使用import声明引入jsdom和localStorage,但却使用require()加载React,这是因为import声明会被提前,我们需要确保在jsdom初始化之后加载React。如果你尝试在DOM就绪前加载React,那么直到你与组件进行交互时它才会开始工作,然后你得到的往往是各种各样的错误,因为React假设这属于非浏览器环境,不使用DOM相关特性。
现在我们有了正确运行的mocha测试,我们也可以轻松获取Istanbul覆盖率检测工具并正常执行:
istanbul cover _mocha -- -R spec
接下来实现我们的加分需求——无相互依赖的交互。这一部分内容来自于我正从事的一个项目,如果你不太感兴趣,大可跳过这一节。
当然,如果你依然感兴趣,那让我们一起讨论一下实现这个目标的方法。
我们需要使松耦合的系统中各部分相互交流,在完美的实现中它们甚至无须知道相互的存在,只须响应请求。这样的任务听起来是否非常熟悉?
你或许曾经听说过微服务这个概念,你甚至可能已经使用过它们。如果你对微服务所知甚少,我推荐你看一下。
如果你懒得看(或者想稍后看)他的演讲,那么简单了解一下微服务的思想:许多小规模、独立的,通过通用接口相互交流的离散服务实体。通用接口可以有多种形式,其中包括:消息总线、表征状态传输(REST,又称表征状态转移)、远程过程调用(RPC)等。
因为我们做的是客户端JavaScript应用,在接口问题上我们的确没有那么多的选择。幸运的是,有一个非常赞的库,它专门处理类似这样的情况——postal.js。
即使它仍然基于回调函数实现底层功能,但是它将消息分为channel和topic两类,提供了非常大的弹性。
通过示例演示所有的这一切是如何工作的,十分容易。
想象一下我们有一个App需要一些认证和URL签名功能来获取数据。通过postal我们可以定义一个认证channel,它将会监听那些签名请求,并通过不同的topic返回已签名的URL,就像这样:
import postal from 'postal';
// get postal channel for current component
const channel = postal.channel("auth");
const signUrl = () =& {
// signing code here
// listen to sign requests
const signAction = channel.subscribe("url.sign", function(url, envelope) {
const signedUrl = signUrl(url);
channel.publish("url.signed", signedUrl);
import postal from 'postal';
// get postal channels
const channel = postal.channel("query");
const authChannel = postal.channel("auth");
// define data fetching stuff
const requestUrl = 'http://...';
const getData = () =& {
// data-fetching logic here
// listen for data requests
const allItemsAction = channel.subscribe("items.all", () =& {
// wait for signed url
authChannel.subscribe("url.signed", (signedUrl) =& {
const data = getData(signedUrl);
channel.publish("items.data", data);
authChannel.publish("url.sign", requestUrl);
在组件中使用postal.js的channels进行通信
这段代码可以很好地工作,因为我们无须了解任何有关其它组件的信息——我们只须了解使用哪个channel和topic。一方面,这意味着管理这些内容的负担落到开发者身上;另一方面,在这种实现的基础上,我们可以轻松地更换认证组件——今天我们使用OAuth,明天我们使用自定义token系统,以后使用其它功能,我们只须更换一下认证组件就可以支持新的工作流。
代码检查和源码映射(Source Map)
最后,我们再为项目加入一些小改进:支持代码检查,启用源码映射。
不支持ES6和React代码,我们将使用代替它。eslint支持JavaScript和JSX的语法,并可以通过插件进行扩展。
将之于Webpack结合非常容易,你只须在你的Webpack配置文件中添加几行代码。下面这个代码片段展示了所需的配置:
var path = require('path');
module.exports = {
devtool: 'inline-source-map',
debug: true,
// your other props here
preLoaders: [
test: /\.jsx?$/,
exclude: /node_modules/,
loader: 'eslint-loader'
// other modules options here
注意node_modules文件夹不包括在检查的范围内,所以程序只会检查你实际的组件代码。
Webpack将在编译过程结束后把所有的检查结果输出到控制台。
Turris.js——汇总一切
结合以上提及的所有内容,我创造了Turris.js——它包含一系列helper包,还有一个yeoman生成器,你可以用它轻松地为ES6 React应用和独立组件搭建脚手架。
如果你对生成器不感兴趣,只想看看应用和独立组件的示例代码,你可以在它们各自的Github仓库中找到它们:还有。
创建新应用
我尝试使创建新应用尽可能地简单,你可以这样创建一个新应用:
确保你已安装最新的io.js和NPM;
从NPM安装yeoman和turris-generator:
npm install -g yo generator-turris
创建一个新文件夹存放你的App,进入这个文件夹,执行turris生成器:
在回答一系列问题后,yeoman将为你完成所有工作;
执行“npm start”,启动你的新App;
访问http://localhost:8080,打开你最喜欢的编辑器并将应用改为你喜欢的样子。
除了为基础应用搭建脚手架外,Turris生成器还提供了三个helper生成器:
组件生成器——将在你的App中生成一个新的组件,可以非常便捷地生成你将不会重用的小组件;
页面生成器——将生成一个新页面并将它插入到React路由中,这里没有什么奇妙之处,它只是一个帮助你节省时间的子生成器;
Docker生成器——将生成一个dockfile,其中包含所有运行App所需的文件。
更多有关使用方法、子生成器、项目结构以及其它内容信息,可以在中找到。
创建一个独立组件
创建一个组件并不难,你可以这样做(需求与主生成器相同):
通过NPM安装turris-generator-component:
$ npm install -g generator-turris-component
为你的组件创建一个新文件夹,进入这个文件夹,执行turris组件生成器:
在回答一系列问题后,yeoman将为你完成所有工作;
执行“npm start”,在调试模式下启动你的组件;
访问http://localhost:8080,打开你最喜欢的编辑器并将应用改为你喜欢的样子。
更多有关使用方法、项目结构以及其它内容信息,可以在中找到。
希望你已在这篇文章中找到有用的内容,或许你甚至已尝试我编写的生成器。即使你没有这样做——也请帮助我宣传一下!如果你已经尝试过——我非常乐意听取任何反馈意见,处理你们可能遇到的问题。当然,也很欢迎大家提交Pull Requests。(译者:刘振涛,审校:陈秋歌)
关于作者:Tim Ermilov,从事移动和Web开发工作。
英文原文:欢迎加入CSDN前端交流群:,进行前端技术交流。&
推荐阅读相关主题:
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号:CSDNnews
相关热门文章基于ES6,使用React、Webpack、Babel构建模块化JavaScript应用-JavaScript-火龙果软件工程
&&&&您可以捐助,支持我们的公益事业。
每天15篇文章
不仅获得谋生技能
更可以追随信仰
基于ES6,使用React、Webpack、Babel构建模块化JavaScript应用
作者:Tim Ermilov 来源:medium 发布于&
1679 次浏览
&&&&评价:
摘要:如何基于ES6,使用React构建一个新JavaScript应用?如何将ES6代码发布到NPM上?又如何在后续项目中使用这些代码?……本文通过具体的编程实践,一一揭晓。
【编者按】本文为《Building modular javascript applications in ES6 with React, Webpack and Babel》的简译内容,讲述了作者基于ES6,使用React、Webpack、Babel构建模块化JavaScript应用的编程心得。
如果你想用React构建一个新的JavaScript应用,而且你还想实践ES6语法中的新特性,此外,你甚至想创建一些可重用组件并发布到NPM上,那么你究竟应该怎样实现这些需求?你如何将ES6代码发布到NPM,又如何在后续的项目中使用这些代码?我花了一些时间解决上面这些问题,现在我愿意与你们分享我习得的新知识。
如果你真的不希望阅读所有的细节,只想看看代码最终的效果――可以直接阅读最后一部分。
我们先来搞清楚我们到底想要得到什么,应该如何去实现。
我们的主要目标是:基于ES6,使用我们自定义的React组件创建一个React应用。其中最棘手的部分是自定义React组件。以下是实现这些目标的需求列表:
自定义组件应该使用ES6编写;
自定义组件应该完全自给自足(使用方法足够简单:安装,导入,渲染);
自定义组件应该提供自身所需的样式(参考第2条,自给自足);
自定义组件应该通过NPM安装(因为bower有很多问题);
最后――所有自定义组件应该有单元测试和代码覆盖率报告;
加分项――自定义组件不应该相互依赖,但是应该能够相互影响。
此外,我们需要一些很棒的调试工具,例如:代码检查、源码映射(因为代码需要编译,所以这是调试的必要工具)。
现在我们已了解所有需求,可以开始寻找满足这些需求的方法。所以,首先需要选定我们将使用的工具集和相关库。
我们要基于ES6开发应用,目前的浏览器暂不完全支持所有新语法特性,所以我们需要将ES6编译为ES5。同时我们希望通过NPM管理自定义组件,需要选用一个兼容CommonJS的工具集。
目前有两种流行的可用选择――Browserify和Webpack。二者都满足我们的大部分需求,考虑到我们的项目需要使用样式文件,而Webpack对非JavaScript文件(例如:样式文件、图片、字体文件)非常友好,所以最终我们将选用Webpack。
Webpack已经能够满足大部分需求,我们将在此基础上加入Gulp.js,帮助我们完成更多任务(例如:单元测试、代码覆盖率检测、静态资源伺服)。
现在我们已经知道如何使用Webpack和Gulp.js来构建代码,可是如何才能满足我们的第一个需求――使用ES6?我们可以使用转译器,帮助我们将ES6代码转译为主流浏览器支持的ES5代码。目前流行的转译器有:Traceur、Babel.js、TypeScript(勉强算是),我们将选用Babel.js,它有一个更好的生态系统(插件、扩展等)。如果你尚不知晓其为何物,请记住这是一个非常棒的项目,我推荐你阅读它们的文档。最棒的是,Babel.js不仅支持ES6语法,它还可以编译JSX,所以我们可以在编译步骤彻底弃用标准React JSX编译器了!
如果你只想使用Babel.js,我推荐你阅读它们的使用文档。Axel Rauschmayer博士曾经撰写《教你使用Babel.js》一文,也值得一读,如果你对JavaScript感兴趣,我也极力推荐订阅他的博客。
现在我们选定了ES6转译器,让我们讨论一下自给自足的问题。如果我们开发纯React组件――那么可以轻松地让它们独立工作(可重用),你甚至可以参考官方指南学习编码方式。但如果我们需要在组件内提供默认的自身样式,需要怎样实现呢?
当然,我们可以选择“纯JS”方法向我们的JSX文件加入内联样式,就像这样:
const render = function() {
const defaultStyle = {
color: 'red',
&div style={defaultStyle}&
I have inline styles
JSX内联样式
这个方法存在一个问题,我们几乎无法通过父应用控制这个组件的样式。而且,如果我们需要加载图片或自定义字体文件,这个方法就会失效。所以,是否有更好的方法呢?
Webpack可以帮你解决这个问题!幸运的是,Webpack 加载器可以加载许多类型的文件。其背后的思想非常简单――在加载过程中动态地对载入文件进行可插拔转换。从本质上来说,加载器为我们处理各种文件。我们将选用一个特殊的babel-loader来将我们的ES6代码转译为ES5代码。
但最酷的是,加载器可以处理任何文件。所以,如果我们想加载样式――我们只需要添加style-loader!最终,我决定使用LESS,它稍微复杂一些――我将创建如下的加载链:
首先,使用less-loader处理*.less文件,将其转换为CSS;
然后,使用css-loader将编译好的css传递给下一个步骤;
最后,使用style-loader将最终的样式引入到生成的代码中。
通过这个加载链,我们可以使用LESS编写组件的样式,下面这段代码演示了这种组件的入口点:
import './style/style.less';
import Component from './src/component';
export default C
借助Webpack将样式引入到JavaScript中
正如你所见,加载样式像导入文件一样简单。的确,由less-loader、css-loader以及style-loader构成的加载链必须要在我们的Webpack配置文件中提前配置好(参考下一节的第一个示例)。
现在我们可以从相互独立的组件中加载样式,但是CSS默认使用全局变量,这意味着如果两个组件中使用了相同的类名,其中一个将被改写,我们如何回避这个问题呢?
我能想出来的最简单的方法是:在HTML标签和样式文件中,使用组件名称作为最外层元素的类名,人为地创建组件的作用域。就像这样:
.component-name {
const render = function() {
&div className=&component-name&&
&span&I have scoped styles&/span&
组件样式的人为作用域
如此一来,所有组件将拥有唯一命名,当他们被封装进同一个应用中时不再产生冲突,能够很好地协同工作。而且,当我们想在应用层重新定义组件样式时,可以使用组件命名作为类名直接改写。
接着,你如何将ES6模块发布到NPM上呢?事实上,你无须这样做。至少目前还不需要。你可以直接向外发布你的原生代码,但这通常是一个糟糕的想法,当你后续想将代码引入到主应用或其它组件中时会感到非常痛苦。当然,你可以通知Webpack(同样也可以通知Browserify)来编译需要用到的代码。但是,如果这样做,你不得不使用Webpack(以及浏览器)来运行各种测试,我通常在命令行中运行测试,因为这样运行速度更快,并且便于后续的自动化测试封装(也就是我们常说的持续集成)。
目前我在项目中应用的最好方法是――同时传送原生ES6代码和编译后的ES5代码,实现这个方法非常简单:
向你的package.json文件添加构建指令;
在预发布阶段运行构建指令;
使用编译后的ES5代码作为主文件;
通过package.json文件的额外字段暴露ES6代码。
它看起来是这样的:
&name&: &es6-component&,
&version&: &1.0.0&,
&description&: &My awesome ES6 component&,
&main&: &es5/component.js&,
&es6&: &index.js&,
&scripts&: {
&build&: &gulp build&,
&prepublish&: &npm run build&
将ES6模块发布到NPM上的package.json
这种方法有两个优点:
在所有ES5代码中,我们可以轻松地引入或require()这个模块,它能够正常工作!
如果我们出于某些原因需要用到模块的源代码,我们同样可以轻松地通知Webpack使用“ES6”字段来加载或引入ES6代码。
单元测试及代码覆盖率
你必须佩服的是,在Babel中配置单元测试和代码覆盖率检测非常简单(得益于Babel伟大的生态系统,正如我之前提到的那样)。
--compilers: jsx?:babel/register
我一直使用mocha作为测试工具,所以我会讲解如何将其应用到项目中。支持ES6代码非常简单,你只需在执行mocha指令时添加一个编译flag(或添加到mocha配置文件)就可以通知mocha使用babel预编译器:
完成这一步之后,就可以在ES6代码中运行测试了,当然你也可以使用ES6来编写测试文件!
现在要处理最棘手的部分――我们有了React组件,我们想使用mocha完成测试,却又不想在浏览器中运行测试(可以运行一个PhantomJS,但是它非常繁重),我们应该如何去做呢?
答案就是jsdom――基于iojs用JavaScript实现了WHATWG的DOM和HTML标准。它比Phantom更轻量,并且满足几乎所有我们测试React所需的功能。
以下是为React配置jsdom环境的测试helper文件的示例:
import localStorage from 'localStorage';
import {jsdom} from 'jsdom';
// init jsdom
global.document = jsdom();
global.window = global.document.defaultV
global.navigator = global.window.
// local storage polyfill
global.window.localStorage = localS
global.localStorage = localS
// import react after dom
const React = require('react/addons');
before(function() {
// expose react and testutils
this.React = R
this.TestUtils = React.addons.TestU
beforeEach(function() {
// create container
this.container = global.window.document.createElement('div');
afterEach(function(done) {
// clean jsdom
this.React.unmountComponentAtNode(this.container);
// timeout
setTimeout(done);
在命令行中运行React测试的jsdom环境
注意我使用import声明引入jsdom和localStorage,但却使用require()加载React,这是因为import声明会被提前,我们需要确保在jsdom初始化之后加载React。如果你尝试在DOM就绪前加载React,那么直到你与组件进行交互时它才会开始工作,然后你得到的往往是各种各样的错误,因为React假设这属于非浏览器环境,不使用DOM相关特性。
现在我们有了正确运行的mocha测试,我们也可以轻松获取Istanbul覆盖率检测工具并正常执行:
istanbul cover _mocha -- -R spec
接下来实现我们的加分需求――无相互依赖的交互。这一部分内容来自于我正从事的一个项目,如果你不太感兴趣,大可跳过这一节。
当然,如果你依然感兴趣,那让我们一起讨论一下实现这个目标的方法。
我们需要使松耦合的系统中各部分相互交流,在完美的实现中它们甚至无须知道相互的存在,只须响应请求。这样的任务听起来是否非常熟悉?
你或许曾经听说过微服务这个概念,你甚至可能已经使用过它们。如果你对微服务所知甚少,我推荐你看一下Fred George对于微服务精彩的讲解。
如果你懒得看(或者想稍后看)他的演讲,那么简单了解一下微服务的思想:许多小规模、独立的,通过通用接口相互交流的离散服务实体。通用接口可以有多种形式,其中包括:消息总线、表征状态传输(REST,又称表征状态转移)、远程过程调用(RPC)等。
因为我们做的是客户端JavaScript应用,在接口问题上我们的确没有那么多的选择。幸运的是,有一个非常赞的库,它专门处理类似这样的情况――postal.js。
即使它仍然基于回调函数实现底层功能,但是它将消息分为channel和topic两类,提供了非常大的弹性。
通过示例演示所有的这一切是如何工作的,十分容易。
想象一下我们有一个App需要一些认证和URL签名功能来获取数据。通过postal我们可以定义一个认证channel,它将会监听那些签名请求,并通过不同的topic返回已签名的URL,就像这样:
import postal from 'postal';
// get postal channel for current component
const channel = postal.channel(&auth&);
const signUrl = () =& {
// signing code here
// listen to sign requests
const signAction = channel.subscribe(&url.sign&, function(url, envelope) {
const signedUrl = signUrl(url);
channel.publish(&url.signed&, signedUrl);
import postal from 'postal';
// get postal channels
const channel = postal.channel(&query&);
const authChannel = postal.channel(&auth&);
// define data fetching stuff
const requestUrl = 'http://...';
const getData = () =& {
// data-fetching logic here
// listen for data requests
const allItemsAction = channel.subscribe(&items.all&, () =& {
// wait for signed url
authChannel.subscribe(&url.signed&, (signedUrl) =& {
const data = getData(signedUrl);
channel.publish(&items.data&, data);
authChannel.publish(&url.sign&, requestUrl);
在组件中使用postal.js的channels进行通信
这段代码可以很好地工作,因为我们无须了解任何有关其它组件的信息――我们只须了解使用哪个channel和topic。一方面,这意味着管理这些内容的负担落到开发者身上;另一方面,在这种实现的基础上,我们可以轻松地更换认证组件――今天我们使用OAuth,明天我们使用自定义token系统,以后使用其它功能,我们只须更换一下认证组件就可以支持新的工作流。
代码检查和源码映射(Source Map)
最后,我们再为项目加入一些小改进:支持代码检查,启用源码映射。
jshint不支持ES6和React代码,我们将使用eslint代替它。eslint支持JavaScript和JSX的语法,并可以通过插件进行扩展。
将之于Webpack结合非常容易,你只须在你的Webpack配置文件中添加几行代码。下面这个代码片段展示了所需的配置:
var path = require('path');
module.exports = {
devtool: 'inline-source-map',
debug: true,
// your other props here
preLoaders: [
test: /\.jsx?$/,
exclude: /node_modules/,
loader: 'eslint-loader'
// other modules options here
注意node_modules文件夹不包括在检查的范围内,所以程序只会检查你实际的组件代码。
Webpack将在编译过程结束后把所有的检查结果输出到控制台。
Turris.js――汇总一切
结合以上提及的所有内容,我创造了Turris.js――它包含一系列helper包,还有一个yeoman生成器,你可以用它轻松地为ES6 React应用和独立组件搭建脚手架。
如果你对生成器不感兴趣,只想看看应用和独立组件的示例代码,你可以在它们各自的Github仓库中找到它们:turris-example-application还有turris-example-component。
创建新应用
我尝试使创建新应用尽可能地简单,你可以这样创建一个新应用:
确保你已安装最新的io.js和NPM;
从NPM安装yeoman和turris-generator:
npm install -g yo generator-turris
创建一个新文件夹存放你的App,进入这个文件夹,执行turris生成器:
在回答一系列问题后,yeoman将为你完成所有工作;
执行“npm start”,启动你的新App;
访问http://localhost:8080,打开你最喜欢的编辑器并将应用改为你喜欢的样子。
除了为基础应用搭建脚手架外,Turris生成器还提供了三个helper生成器:
组件生成器――将在你的App中生成一个新的组件,可以非常便捷地生成你将不会重用的小组件;
页面生成器――将生成一个新页面并将它插入到React路由中,这里没有什么奇妙之处,它只是一个帮助你节省时间的子生成器;
Docker生成器――将生成一个dockfile,其中包含所有运行App所需的文件。
更多有关使用方法、子生成器、项目结构以及其它内容信息,可以在项目仓库的Readme文件中找到。
创建一个独立组件
创建一个组件并不难,你可以这样做(需求与主生成器相同):
通过NPM安装turris-generator-component:
grunt traceur
为你的组件创建一个新文件夹,进入这个文件夹,执行turris组件生成器:
在回答一系列问题后,yeoman将为你完成所有工作;
执行“npm start”,在调试模式下启动你的组件;
访问http://localhost:8080,打开你最喜欢的编辑器并将应用改为你喜欢的样子。
更多有关使用方法、项目结构以及其它内容信息,可以在项目仓库的Readme文件中找到。
希望你已在这篇文章中找到有用的内容,或许你甚至已尝试我编写的生成器。即使你没有这样做――也请帮助我宣传一下!如果你已经尝试过――我非常乐意听取任何反馈意见,处理你们可能遇到的问题。当然,也很欢迎大家提交Pull Requests。(译者:刘振涛,审校:陈秋歌)
关于作者:Tim Ermilov,从事移动和Web开发工作。
更多课程...&&&
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
|&京ICP备号&京公海网安备号

我要回帖

 

随机推荐