Javascript异步流程控制之Promise(1)-Angular $q简介

原文写于 2015-01-25

先来说说什么是Promise吧

Promise是抽象异步处理对象以及对其进行各种操作的组件。 其详细内容在接下来我们还会学到，Promise并不是从JavaScript中发现的概念。
Promise最初被发现是在 E言語中， 它是基于并列/并行处理设计的一种编程语言。

简言之，Promise就是用于改善异步编程体验的一种编程模型，它提供一系列的api和方法论，让你能更优雅的解决异步编程中出现的一些问题。目前很多第三方框架或类库(如Angular和JQuery)都依照Promise/A+社区制定的规范做了相应的实现(JQuery基于历史原因很多地方与Promise规范不一致，so不建议通过JQuery源码学习Promise)，最主要的是，Promise现在已经成为ES6的既定标准，目前部分高版本浏览器已原生支持Promise(后面有机会给出demo)，所以我们还是很有必要来了解一下这到底是一个什么东西。

首先来看看，Promise的核心竞争力在哪

以前我们在处理一系列有依赖性的回调的时候，我们的代码是这样写的

step1(function (value1) {
    step2(value1, function(value2) {
        step3(value2, function(value3) {
            step4(value3, function(value4) {
                // Do something with value4
            });
        });
    });
});

是的，就是一层层的回调嵌套，传说中的回调地狱
那么如果我们换成Promise的方式来实现呢

step1().then(step2).then(step3).then(step4)

效果显而易见，代码简单逻辑清晰，异步的回调嵌套写法变成了同步(本质上当然还是异步的)的写法看上去是不是优雅多了

目前，Angular基于现在流行的NodeJs异步流程控制库Q实现了一个微缩版的Q，它提供了一些最常用的规范的Promise API，并对外提供了$q这样一个service，这里我们介绍一下angular框架中主要有哪些api及相应的使用场景。(声明一点，angular中所有的ajax请求均返回promise)

1. Promise.then() 将回调嵌套变成链式调用。then可以接两个参数,sucessCallback 和 errorCallback，即then(successCb, errorCb)
2. Deferred.resolve(val) 通知promise请求处理完毕，并将处理结果传给回调函数
3. Deferred.reject(msg) 通知promise请求出现异常，将异常信息传给回调函数
4. $q.when(val/fn) 将任意 对象/函数 包装成promise，返回包装好的promise
5. $q.all(promises).then() 当所有promise都成功解析后流程才继续往下走
   使用场景

Promise.then()

// 通常，我们处理多层顺序依赖的异步调用，我们会这样去写
$http.get().success(function (val1){
    $http.get(val1).success(function (val2){
        $http.get(val2).success(function (val3){
            console.log(val3);
        })
    });
});

// 当用Promise来处理时，写法会变成这样
function funcA(val1){
    return $http.get(val1).suceess(function (val2){
        return val2;   
    })
}

function funcB(val2){
    return $http.get(val2).suceess(function (val3){
        return val3;   
    })
}

function funcC(val3){
    console.log(val3);
}
$http.get().then(funcA).then(funcB).then(funcC);

// 很显然，使用了Promise方式代码可读性变的强很多

Deferred.resolve

// Deferred.resolve用于通知promise结果已经处理好，可以开始处理回调了
// 假设我们有这样一个业务，按钮点击时的处理逻辑依赖于另一个函数异步返回的数据，就像这样
var a;
setTimeout(function(){
    a = 10;
},5000);
dom.onclick = function(){
    console.log(a);
}

// 我们总不能在onclick里轮询直到a被赋值吧。。
// 有了Promise一切变得简单
var defer = $q.defer(),
    a;
setTimeout(function (){
    defer.resolve(10);
},5000);
dom.onclick = function(){
    defer.promise.then(function(a){
        console.log(a);
    });
}

Deferred.reject

// 用法同deferred.resolve，只不过它调用之后会走失败回调
setTimeout(function(){
    defer.reject(10);
},5000);
defer.promise.then(function successCb(a){
    console.log(a+"success");
}, function errorCb(a){
    console.log(a+"error");
});

// 5秒后打出 "10error"

Promise.all

// 这个api就非常给力了，假设我们有这样一个场景
// 页面上有A、B、C、D四块区域，其中A、B、C三块数据都是ajax获取的，D展示的数据需要综合A、B、C三个的数据
// 难道我们得在 A 的请求回调里调用 B ,然后再B请求回调里调C这样一层层嵌套，直到所有请求准备好了再去处理D ？这样整个页面在同一时间只能有一个请求发出，效率太低
// 可以这样写

$q.all([promiseA,promiseB,promiseC]).then(funcD)

// 这样页面在同一时间会发出三个请求，当所有请求都好了之后再去处理D页面，代码不仅变得更清晰而且效率更高
最后介绍一下Promise.race([promises])，这个api angular并没有做实现，但是它已列入Promise/A+规范中，这里提一下
Promise.race([promises])与Promise.all([promises])类似，只不过Promise.all是与集运算，而Promise.race()是或集运算，当promises中有一个被resolve了就会继续后面的then

Promise.race

// 当promiseA或promiseB其中有一个被resolve，则后面funcT会被执行
// 使用场景有：进入一个页面时 当用户点击某个按钮或过5s 则展示某个提示，使用这个api会很方便
Promise.race([promiseA,promiseB]).then(funcT);

SpringMVC4.1之Controller层最佳实践

原文写于 2014-09-28

前几天突发奇想想去看看spring现在到升级到什么版本了，有些啥New Features。结果发现了一个很人性化的新注解，刚好最近在构建客服系统新的接口层结构，然后重新研究了下spring mvc，一些成果跟大家分享一下（SpringMVC4.1的jackson版本升级到了2.x，不再支持Jackson1.x，同学们注意。详细代码请右转：seed )。

先说说我们要实现的目标(接口层)：

• 统一的响应体、请求体，规避Map、List作参数或者响应结果的方式(尤其是参数用Map来包装，这种代码有时候看起来真的让人很沮丧)
• 统一的错误信息
• 统一的请求数据校验
• 统一的接口异常捕获

首先来介绍下springMVC新增的一个很人性化的注解：

@RestController

@RestController组合了@controller和@responsebody，使用该注解声明的controller下的每一个@RequestMapping方法，都会默认加上@responsebody，即默认该controller提供的全部是rest服务，返回的不会是视图。

@RestController
public class DemoRestController {
    @Resource
    private DemoService demoService;

    @RequestMapping(value = "getUser", method = RequestMethod.GET)
    public ResponseResult<List<User>> getUser(String userName) {
        // do something
    }   
}

基于开头提到的四个目标，我们以代码的形式来说明一下具体的实现方案

• 统一的请求体、响应体

思路：所有的rest响应均返回一致的数据格式，所有的post请求均采用bean接收。（不要使用List、Map万金油。。。）
目的：统一的响应体能确保rest接口的一致性，同时可以提供给前端js一个可封装http请求的环境（如：封装的http错误日志、结果拦截等）（吐槽一句，有时候我们想在前端做统一的响应拦截和日志处理，可是接口返回的数据格式五花八门，实在让人无能为力。。。） post请求均采用bean接收可以使得代码更具可读性，直接通过bean可以获知接口所需参数，而不是一行行读代码看你从map里面get出了些什么玩意。
ps:部分思路来源于忠诚度项目接口实现方式，特此表示感谢！
统一响应体

@JsonInclude(JsonInclude.Include.NON_EMPTY)
public class ResponseResult<T> {
    private boolean success;
    private String message;
    private T data;
    /* 不提供直接设置errorCode的接口，只能通过setErrorInfo方法设置错误信息 */
    private String errorCode;
    private ResponseResult() {
    }
    .........
}

统一结果生成方式

public class RestResultGenerator {
    private static final Logger LOGGER = LoggerFactory.getLogger(RestResultGenerator.class);

    /**
     * 生成响应成功(带正文)的结果
     *
     * @param data    结果正文
     * @param message 成功提示信息
     * @return ResponseResult
     */
    public static <T> ResponseResult<T> genResult(T data, String message) {
        ResponseResult<T> result = ResponseResult.newInstance();
        result.setSuccess(true);
        result.setData(data);
        result.setMessage(message);
        if (LOGGER.isDebugEnabled()) {
            LOGGER.debug("--------> result:{}", JacksonMapper.toJsonString(result));
        }
        return result;
    }
    ........
}

调用示例

@RestController
public class DemoRestController {
    @Resource
    private DemoService demoService;

    @RequestMapping(value = "getUser", method = RequestMethod.GET)
    public ResponseResult<List<User>> getUser(String userName) {
        List<User> userList = demoService.getUser(userName);
        return RestResultGenerator.genResult(userList, "成功!");
    }   
}

• 统一的错误信息

思路：需要使用errorCode来声明的错误信息，统一通过enum定义，ResponseResult不提供单独设置errorCode的接口

public class RestResultGenerator {
    private static final Logger LOGGER = LoggerFactory.getLogger(RestResultGenerator.class);

    .......

    /**
     * 生成响应失败(带errorCode)的结果
     *
     * @param responseErrorEnum 失败信息
     * @return ResponseResult
     */
    public static ResponseResult genErrorResult(ResponseErrorEnum responseErrorEnum) {
        ResponseResult result = ResponseResult.newInstance();
        result.setSuccess(false);
        result.setErrorInfo(responseErrorEnum);

        if (LOGGER.isDebugEnabled()) {
            LOGGER.debug("--------> result:{}", JacksonMapper.toJsonString(result));
        }

        return result;
    }
}

• 统一的请求数据校验
  思路：基于注解的bean校验，采用JSR-303的Bean Validation。
  目的：xx参数不能为空，格式必须为xxx等校验就不用在接口中去硬编码干扰业务逻辑了。让框架统一帮忙验证

bean示例

@JsonInclude(JsonInclude.Include.NON_EMPTY)
public class User {

    @NotBlank
    private String userName;

    @NotNull
    @Max(150)
    @Min(1)
    private Integer age;

    private User() {
    }
}

调用示例

@RestController
public class DemoRestController {
    @Resource
    private DemoService demoService;

    @RequestMapping(value = "saveUser", method = RequestMethod.POST)
    public ResponseResult saveUser(@Valid @RequestBody User user, Errors errors) {

        if (errors.hasErrors()) {
            return RestResultGenerator.genErrorResult(ResponseErrorEnum.ILLEGAL_PARAMS);
        } else {
            demoService.saveUser(user);
            return RestResultGenerator.genResult("保存成功!");
        }
    }
}

由于依赖于JSR-303规范，我们的pom文件需要加入新的依赖
maven配置

<dependency>
    <groupId>javax.validation</groupId>
    <artifactId>validation-api</artifactId>
    <version>1.1.0.Final</version>
</dependency>
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>5.0.1.Final</version>
</dependency>

• 统一的接口异常捕获

  思路：起初想通过代码中try..catch的方式捕获异常，然后通过RestResultGenerator生成错误信息。后来觉得这种方式太傻了，然后想到通过aop的方式，以Controller的RequestMapping为切面织入异常捕获代码，然后返回错误信息。再后来发现springMVC早在3.x时代便提供了@ExceptionHandler注解。。。再后来又发现了@ControllerAdvice。。。这不就是我想要的嘛!! 可见使用一门技术前对其有一定的系统认知该多么重要，不仅能避免重复造轮子还能避免坑自己坑别人
  目的：无侵入式的异常捕获，不干扰业务逻辑

  名词解释：

  • ExceptionHandler：顾名思义，异常处理器。单独的ExceptionHandler没什么特别之处，配合ControllerAdvice就会分分钟变神器!
  • ControllerAdvice: 从命名我们就能猜到，这家伙肯定是基于aop实现的一个东西，用于增强controller功能的。它可以把@ControllerAdvice注解内部使用@ExceptionHandler、@InitBinder、@ModelAttribute注解的方法应用到所有的 @RequestMapping注解的方法。其中ExceptionHandler实际作用最大，其他两个用的少。Spring3.x时代ControllerAdvice会增强一个servlet中的所有controller，Spring4以后 ControllerAdvice又得到了增强，可以应用于controller的子类，控制范围更精确。

  代码示例
  使用controllerAdvice实现的全局异常处理

// 指定增强范围为使用RestContrller注解的控制器
@ControllerAdvice(annotations = RestController.class)
public class RestExceptionHandler {

    private static final Logger LOGGER = LoggerFactory.getLogger(RestExceptionHandler.class);

    /**
     * bean校验未通过异常
     *
     * @see javax.validation.Valid
     * @see org.springframework.validation.Validator
     * @see org.springframework.validation.DataBinder
     */
    @ExceptionHandler(UnexpectedTypeException.class)
    @ResponseBody
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    private <T> ResponseResult<T> illegalParamsExceptionHandler(UnexpectedTypeException e) {
        LOGGER.error("--------->请求参数不合法!", e);
        return RestResultGenerator.genErrorResult(ResponseErrorEnum.ILLEGAL_PARAMS);
    }
}

Controller里面不用写任何多余的代码，如果@Valid校验失败接口会抛出UnexpectedTypeException从而被ControllerAdvice捕获并返回错误信息，httpstatus为503 Bad Request 错误

@RestController
public class DemoRestController {
    @Resource
    private DemoService demoService;

    @RequestMapping(value = "saveUser", method = RequestMethod.POST)
    public ResponseResult saveUser(@Valid @RequestBody User user) {
        demoService.saveUser(user);
        return RestResultGenerator.genResult("保存成功!");
    }
}

注意这里参数列表里面就不要加Errors或其子类作参数了，有这个参数校验失败就不会抛异常，而是把错误信息填充到Errors对象中。

写在最后

至此，在Controller层我们一开始的目标基本上都已经达成了，之后我们编写接口只需要实现业务逻辑，参数校验、异常捕获等工作全部交由外围设施处理，而不是手动编码做重复工作。SpringMVC部分还有很多已有的东西我们没有开发，有点暴殄天物的感觉。磨刀不误砍柴工，这样才能避免重复造轮子跟写出可维护的代码。虽然是码农，但是也不能只满足于复制粘贴吧。。。

附（目前大部分项目中关于springMVC错误的(更准确说是不合理的)配置一览表）：

• schema无效引入：也就是xml头部引入的xsd，很多都是无效的引入，不过切换到idea之后IDE会提示你哪些引入是无效的。
• <context:annotation-config /> 和 <context:component-scan />：component-scan会自动加上annotation-config功能，有了component-scan不用再写annotation-config了。参见spring官方reference
• applicationContext.xml中配置了context:component-scan，在springmvc-servlet.xml中又配置了context:component-scan，这样会导致容器中的bean注册两次。
  更合理的配置

// applicationContext.xml
<context:component-scan base-package="com.shuyun.channel">
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller" />
    <context:exclude-filter type="annotation" expression="org.springframework.web.bind.annotation.RestController" />
    <context:exclude-filter type="annotation" expression="org.springframework.web.bind.annotation.ControllerAdvice" />
</context:component-scan>

// springmvc-servlet.xml
<context:component-scan base-package="com.shuyun.channel" use-default-filters="false">
    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller" />
    <context:include-filter type="annotation" expression="org.springframework.web.bind.annotation.RestController" />
    <context:include-filter type="annotation" expression="org.springframework.web.bind.annotation.ControllerAdvice" />
</context:component-scan>

spring容器不注册controller层组件，controller组件由springMVC容器单独注册。
更多详细代码请访问：spring-mvc4-seed，欢迎拍砖！

基于ui-router的非侵入式angular按需加载方案

用过angular1.x(后面提到的angular均指代的angular1.x框架)的同学应该都知道，angular自身的模块系统是不具备按需加载的能力的，笔者也赞同angular的模块系统是真正称得上设计上的败笔的观点的。2015年被黑的最惨的前端主流框架莫过于angular了，但实际上angular真正设计上的硬伤只有两个：鸡肋的模块系统以及相比其他MVVM框架略显丑陋的脏值检测机制。关于其他各种所谓致命缺陷的立论其实都是站不住脚的，这些观点的提出我可以归结于使用者对angular的不熟悉，不服的同学欢迎来辩😂

angular模块系统的问题

扯远了，说回正题。由于angular自身模块系统的限制，module不支持运行时添加依赖，也就是我们在定义入口模块时必须声明所有依赖项。当我们面临多项目整合的场景时(往往这类场景有按需加载的需求)，这个就很恶心了，我们总不能在入口页写好所有可能会嵌入系统的项目的依赖项吧，而且要确保入口模块能找到所有依赖项对应的模块，相应的js还必须在入口处就加载好。。 更多关于angular模块化的问题，具体可以参见民工叔的这篇文章Angular的模块机制

市面上angular实现按需加载的通常方案

目前市面上流行的解决方案大概是这样的：基于requirejs等模块加载器，我们子模块的代码包裹在requirejs的模块定义语法下(define)，然后在具体需要的时候在require回调里invoke我们子模块的controller或service等，可以参见这个seed项目angular-requirejs-seed

但是这种方式也有一些明显的问题：

1. requirejs配合angular实现的那一套按需加载的方案实在是太挫了，真的是有碍观瞻啊！😂它是一套完全侵入式的方式，我个人是无法接受的。而且我认为在中小型规模的系统中，基于angular框架，我们自己需要写的代码量其实不会太大，即使在首页全部引入，在经过简单的合并压缩再配合gzip，文件体积完全在可控范围内，按需加载在这样的场景下价值有限。这也是我一直拒绝在angular体系中引入requirejs的原因。
2. 如果我们采用angular的纯module的方式开发，那么我们自然会有包含各种controller、service、directive的不同模块，类似angular.module('directives',[]).directive('grid',function(){})
   的写法，而这些子模块必须在入口模块定义时声明其为依赖项，像这样angular.module('app',['directives'])即便你采用requirejs做按需加载。
3. 我们不采用子单元纯module的方式开发，而是将所有的子单元都挂载在入口模块上，子模块写法类似angular.module('app').directive('grid',function(){})，这种做法副作用会相对少点，但是如果碰到多个项目在各个系统之间作嵌入时，很难做到不用修改代码即可完成嵌入，除非你能确保所有的系统入口模块命名一样。

基于ui-router的解决方案

刚好最近公司在做整个系统的去iframe化(没错之前各个产品嵌入主系统的做法是通过iframe。。不要笑！！😂)，因为各个产品之间的切换是通过tab完成的，tab的切换又是通过ui-router控制去定位到各个产品的入口html，所以基于ui-router，我的思路是这样的：

1. 首先要理清ui-router的工作方式：tab切换时触发ui-router的路由，ui-router会通过配置好的路由规则找寻相应的模板配置(这里假设我们路由配置的都是templateUrl的方式)，得到url后会去发起ajax请求拿模板，拿到模板再会填充到ui-view内容区，最后做compile、link处理(省去其他细节)，这时候ui-view区域显示的就是编译好的模板内容了。
2. 基于此，我们可以在模板做编译之前，分析并拿到模板中的script标签，然后通过简单的脚步加载器将模板中定义的js加载到浏览器内存里，在所有的js资源加载完毕之后再去调用编译流程，一切OK！这里要顺带解释一个事情，因为ui-router里采用element.html(tpl)的方式将模板填充到ui-view中的，所以模板中的script标签并不会被浏览器按正常方式解析，而link、style标签不会受到影响(出于安全考虑？具体原因没查到知道的同学请不吝指教)。

但是我们要做的当然不能是直接去找到ui-router这一块的代码然后修改源码，这种做法是有违开闭原则的也是我一直批判的方式，不到万不得已绝不要去修改第三方插件的源码！ui-router处理路由模板的主逻辑在uiView指令里，然后angular里面又提供了强大的decorator机制。开码！

angular
    .module('ui.router.requirePolyfill', ['ng', 'ui.router', 'oc.lazyLoad'])
    .decorator('uiViewDirective', DecoratorConstructor);

  /**
   * 装饰uiView指令,给其加入按需加载的能力
   */
  DecoratorConstructor.$inject = ['$delegate', '$log', '$q', '$compile', '$controller', '$interpolate', '$state', '$ocLazyLoad'];
  function DecoratorConstructor($delegate, $log, $q, $compile, $controller, $interpolate, $state, $ocLazyLoad) {

    // 移除原始指令逻辑
    $delegate.pop();
    // 在原始ui-router的模版加载逻辑中加入脚本请求代码,实现按需加载需求
    $delegate.push({

      restrict: 'ECA',
      priority: -400,
      compile : function (tElement) {
        var initial = tElement.html();
        return function (scope, $element, attrs) {

          var current = $state.$current,
            name = getUiViewName(scope, attrs, $element, $interpolate),
            locals = current && current.locals[name];

          if (!locals) {
            return;
          }

          $element.data('$uiView', {name: name, state: locals.$$state});

          var template = locals.$template ? locals.$template : initial,
            processResult = processTpl(template);

          var compileTemplate = function () {
            $element.html(processResult.tpl);

            var link = $compile($element.contents());

            if (locals.$$controller) {
              locals.$scope = scope;
              locals.$element = $element;
              var controller = $controller(locals.$$controller, locals);
              if (locals.$$controllerAs) {
                scope[locals.$$controllerAs] = controller;
              }
              $element.data('$ngControllerController', controller);
              $element.children().data('$ngControllerController', controller);
            }

            link(scope);
          };

          // 主要实现
          // 模版中不含脚本则直接编译,否则在获取完脚本之后再做编译
          if (processResult.scripts.length) {
            loadScripts(processResult.scripts).then(compileTemplate);
          } else {
            compileTemplate();
          }

        };
      }

    });

    return $delegate;

最早期我自己实现了一个简单的script-loader用来做基本的动态脚本加载，但是后来发现一个问题：angular框架下我们单单的只是加载脚本是没用的，我们必须把脚本定义的module注入到主app的module下才有意义。尽管在下仔细读过大部分angular的核心部件代码，但是动态注册模块这个事情难度还是很大的，改造工作一度停滞不前。。直到我发现了这个库ocLazyLoad，这之后事情就好办了。
附上完整的实现代码：ui-router-require-polyfill，文档。这里面为了解决脚本加载的时序问题，我在loadScript方法里加入了提取script seq属性的机制用于确定脚本顺序，同时为了解决gulp脚本合并时的问题，个人简单改造了下gulp-usemin插件，改造后的插件在这里，要做发布的脚本合并时请配合使用这个改造过的插件。[更新：pull request已被合并，可以直接install gulp usemin最新版本]

写在最后

这一套方案目前是我能想到的最接近完美的方案，最主要的是它是非侵入式而且基本不需要对原有angular体系下的代码做任何改造，即可实现按需加载&模块移植的需求的方式。如果有同学有改进建议或者更好的方案，欢迎一起探讨。

前端工程之构建工具-gulp实战

原文写于 2014-10-24

对前端构建自动化有所了解的同学应该都听过大名鼎鼎的grunt，但是grunt作为前端自动化构建工具的领头羊现在越来越受到诟病。大而全已经不适应这个时代了，这个时代需要的是小而美的工具及插件。什么都想干往往意味着什么都干不好，YUI的死掉至少说明了近年前端的发展趋势。grunt的不足及弊端大家可以参考这篇文章。后起之秀gulp大有取代grunt的趋势(gulp的github的stars目前已经超过grunt了)，本文主要介绍如何通过gulp实现自动化压缩、合并以及文件的修改。
首先来说说我们想要实现的功能吧

• 最基础的js、css合并压缩(html看个人爱好...不过有坑请慎重考虑...)
• 开发环境在/src目录下，发布环境在/dist目录下。开发人员只需要维护/src目录代码，/dist目录不应该有任何的人为干预(人工不靠谱，出错查不出...)
• 发布时不需要手动更新静态资源版本号。如果我们的js、css有改动，我们不能说每次发布后都告诉用户去清缓存才能更新代码。古老的做法是每次发布时加上版本号，类似<script src=xxx.js?v=0.1></script>。这样太麻烦。合理的应该是，只要我们的源码有改动，那么我们引用的资源版本号就应该自动更新。

来看看我们怎样通过gulp实现我们的前端工程自动化的吧
首先是一个源码层级的index.html，差不多长这样

<!--
 Created by kui.liu on 2014/05/29 14:34.
-->
<!DOCTYPE html>
<html ng-app="invoiceApp">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

    一堆css文件。。。。
    <!-- build:css css/app.css -->
    <link href="/src/css/bootstrap-tooltips.css" rel="stylesheet">
    <link href="/src/js/lib/jquery-ui/development-bundle/themes/base/jquery.ui.theme.css" rel="stylesheet">
    <link href="/src/js/lib/jquery-ui/development-bundle/themes/base/jquery.ui.core.css" rel="stylesheet">
    <link href="/src/js/lib/jquery-ui/development-bundle/themes/base/jquery.ui.datepicker.css" rel="stylesheet">
    <link href="/src/js/lib/jQuery-Timepicker-Addon/dist/jquery-ui-timepicker-addon.min.css" rel="stylesheet">
    <link href="/src/css/float-tips.css" rel="stylesheet"/>
    <link href="/src/css/ccms.css" rel="stylesheet">
    <link href="/src/css/app.css" rel="stylesheet">
    <link href="/src/js/lib/ccms_pop/css/style.css" rel="stylesheet">
    <!-- endbuild -->

    <style>
        [ng\:cloak], [ng-cloak], [data-ng-cloak], [x-ng-cloak], .ng-cloak, .x-ng-cloak {
            display: none !important;
        }
    </style>
    <title>账户管理</title>
    <script>
        //  设置资源文件目录，必需!!
        window.ResourceDir = "/src/";
    </script>
</head>
<body ng-cloak class="ng-cloak" ng-controller="AppCtrl"> 
    此处省略若干结构。。。
    一堆js文件
    <!-- build:js js/app.js -->
    <script src="/src/js/lib/jquery/jquery-1.11.1.js"></script>
    <script src="/src/js/lib/jquery-ui/development-bundle/ui/jquery.ui.core.js"></script>
    <script src="/src/js/lib/jquery-ui/development-bundle/ui/jquery.ui.datepicker.js"></script>
    <script src="/src/js/lib/jQuery-Timepicker-Addon/dist/jquery-ui-timepicker-addon.min.js"></script>
    <script src="/src/js/lib/jQuery-Timepicker-Addon/dist/i18n/jquery-ui-timepicker-zh-CN.js"></script>
    <script src="/src/js/lib/bootstrap/bootstrap-tooltips.js"></script>
    <script src="/src/js/lib/ccms_pop/js/yunat_pop.js"></script>
    <script src="/src/js/float-tips.js"></script>
    <script src="/src/js/lib/angular/angular.js"></script>
    <script src="/src/js/lib/angular/angular-locale_zh-cn.js"></script>
    ...........
    <!-- endbuild -->
</body>
</html>

然后是我们开发时的目录结构
image2014-10-26 15:30:4.png
然后我使用gulp定义了一系列构建任务后，执行一下命令 gulp build (假设你也写了个名为build的任务)
我们的工程变成这样了
首先是工程目录
image2014-10-26 15:32:40.png
然后是/dist/index.html

<!--
 Created by kui.liu on 2014/05/29 14:34.
-->
<!DOCTYPE html>
<html ng-app="invoiceApp">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">


    <link rel="stylesheet" href="/dist/css/app-cb402b9f.css"/>

    <style>
        [ng\:cloak], [ng-cloak], [data-ng-cloak], [x-ng-cloak], .ng-cloak, .x-ng-cloak {
            display: none !important;
        }
    </style>
    <title>账户管理</title>
    <script>
        //  设置资源文件目录，必需!!
        window.ResourceDir = "/dist/";
    </script>
</head>
<body ng-cloak class="ng-cloak" ng-controller="AppCtrl">
    ........
    <script src="/dist/js/app-3db90639.js"></script>
</body>
</html>

可以看到，/dist目录如期而至，而且长得跟我们预想的一样，然后是/dist/index.html，所有的css和js引用均指向一个压缩合并后的文件，眼尖的同学会发现，后面跟的那一串奇怪的数字是啥，如
app-3db90639.js。中划线后面那串数字是我们通过gulp计算了合并文件的MD5之后算出的hash值，也就是说，只要你的源码有改动，那么这个hash值便会自动追加到合并文件后面，而不需要你每次手动修改版本号那种古老的做法，一切都是gulp帮我们做好，我们需要做的就是敲一行命令就好了。赞一个！

下面具体介绍一下gulp怎么玩才能达到上文的效果

1. 首先你要有个nodejs环境。nodeJs

2. 安装gulp、bower(假设你有用到)等node组件

   node install gulp -g
   node install gulp --save-dev

3. 引入gulp合并、压缩等插件(package.json文件)

   "devDependencies": {
       "gulp"            : ">=3.8.8",
       "del"             : ">=0.1.3",
       "gulp-minify-css" : ">=0.3.10",
       "gulp-minify-html": ">=0.1.6",
       "gulp-replace"    : ">=0.4.0",
       "gulp-rev"        : ">=1.1.0",
       "gulp-uglify"     : ">=1.0.1",
       "gulp-usemin"     : ">=0.3.8",
       "run-sequence"    : ">=1.0.1"
   }

4. 构建gulp任务流，就像这样

   /**
    * @author kui.liu
    * @since 2014/09/29 上午11:45
    */
   "use strict";
   var webRoot = "src/main/webapp/",
       gulp = require('gulp'),
       del = require('del'),
       runSequence = require('run-sequence'),
       minifyCss = require('gulp-minify-css'),
       minifyHtml = require('gulp-minify-html'),
       uglify = require('gulp-uglify'),
       rev = require('gulp-rev'),
       replace = require('gulp-replace'),
       usemin = require('gulp-usemin');
   /*------------------------- 清空dist目录 -----------------------------*/
   gulp.task('clean', function (cb) {
       del(webRoot + "dist/*", cb);
   });
   /*------------------------- 拷贝资源文件 -----------------------------*/
   gulp.task('copy-tpl', function () {
       return gulp.src(webRoot + 'src/tpls/**/*.html')
           //        .pipe(minifyHtml({empty: true, quotes: true}))
           .pipe(gulp.dest(webRoot + 'dist/tpls'));
   });
   gulp.task('copy-font', function () {
       return gulp.src(webRoot + 'src/fonts/*')
           .pipe(gulp.dest(webRoot + 'dist/fonts/'));
   });
   gulp.task('copy-image', function () {
       return gulp.src(webRoot + 'src/images/**/*')
           .pipe(gulp.dest(webRoot + 'dist/images'));
   });
   gulp.task('copy-jqueryui-image', function () {
       return gulp.src(webRoot + 'src/js/lib/jquery-ui/development-bundle/themes/base/images/*')
           .pipe(gulp.dest(webRoot + 'dist/css/images'));
   });
   
   /*------------------------- 对首页引用的css、js作合并压缩，并根据文件md5值自动更新 -----------------------------*/
   /*------------------------- 首页html需要加入build标识，具体参照gulp-usemin插件文档 -----------------------------*/
   gulp.task('usemin', function () {
       return gulp.src(webRoot + 'src/index.html')
           .pipe(replace(/\/src\/(js|css)/g, '$1'))
           .pipe(usemin({
               css: [minifyCss({keepSpecialComments: 0}), rev()],
               //            html: [minifyHtml({empty: true, quotes: true})],
               js : [uglify(), rev()]
           }))
           .pipe(replace(/(js\/|css\/)/g, "/dist/$1"))
           .pipe(replace(/\/src\//g, "/dist/"))
           .pipe(gulp.dest(webRoot + 'dist/'));
   });
   // 定义构建任务队列
   gulp.task('build', function (cb) {
       runSequence('clean', ['copy-tpl', 'copy-font', 'copy-image', 'copy-ccmsPop-image', 'copy-jqueryui-image', 'usemin'], cb);
   });

   gulp采用管道流机制定义任务，任务的定义跟使用变得更易用和清晰。要运行单个定义的任务很简单，比如上面定义的clean任务：

   gulp clean

   一般情况下我们不会只执行一个构建任务，如果要一个个任务去敲命令显然是效率低下的，这里引入runSequence插件，从而自定义任务队列，比如上面我们定义build任务用来执行所有的合并、压缩的任务，执行方式跟其他任务一样：

   gulp build

   有的时候我们还用了bower等其他工具，不仅仅是gulp。那么构建工程的时候需要bower install,然后gulp build。懒人总想找到更简单的方式，我们在package.json中加入这个

   "scripts"        : {
       "start": "npm install & bower install --allow-root & gulp build"
   }

   这样我们构建项目只需要一个命令就OK

   npm start

   命令跑完之后一切就都变成了你想要的模样。就是这么简单。so easy！麻麻再也不用担心我每次发布都要小心翼翼了。

ps:由于我们node配置文件是放在项目根路径下的，而maven只打包webapp下的资源，所以如果你不想每次发布前还要手动跑node命令然后提交编译目录，配合bamboo可以在maven打包前加上脚本命令，如图
image2014-10-27 10:7:27.png

更多详细代码请移步：source code

前端已不止于前端－序章

原文写于 2015-04-15

额，那啥，我又准备写一个系列了

楔子

某天有网友在知乎上提问：如何反驳 ［程序＝算法＋数据结构］，前端不懂算法不懂数据结构根本就不能算程序员！
伟大的 计算机之子 @寒冬winter 给了一个万能的解决方案，并列出了技术界吵架的无敌五式，其中有一条就是：

XX发展到现在，概念跟以前已经有了很大的变化。

套用到具体案例，你可以这样反驳：前端发展到现在，概念跟以前已经有了很大的变化。
看上去这更像是寒冬老师的戏谑之言，但是用来描述前端发展的现状，实在是再合适不过。

是的，前端发展到现在，概念跟以前已经有了很大的变化。

前端发展简史

星星之火源于09年中旬发布的NodeJs，被贴上后端js标签的javascript自出生以来再次吸引了技术界的眼球，js再也不局限于浏览器那一块方寸之地了。越来越多的前端工程师开始尝试进入后端工程领域，同时也吸引了一批后端工程师来试水所谓的能跑在服务器上的js。各种不同技术背景的开发人员的加入，帮助NodeJs社区发展的欣欣向荣，新的开发环境中遭遇到更多以前浏览器端js开发未曾遭遇(或者说未被重视)的问题，于是各种背景的开发人员为javascript引入了更多其他领域的**和方法论。于是，各种模块化解决方案应运而生，AMD代表的requireJs、CMD代表的sea.js，各种异步流程控制解决方案，Promise、thunk、co 等等。前端MVC代表的Backbone.js 以及 在 其基础上衍生的出来的 MVVM 框架代表 angularJs 使得后端工程师也能快速的开发出易于维护的页面。时间走到2013年，前端领域开始井喷式发展，越来越多的概念被提出。angularJs将前端工程师从繁重的DOM操作中解放出来，从而有更多的精力去关注附加值更高的领域；基于模块化的开发让人们越来越意识到前端工程化的重要性，requireJs、seajs、fis等以及前后端通吃的Browserify、webpack；基于npm的一系列构建工具也让一切工程化想法得以实现，bower、grunt、gulp；HTML5+CSS3 Canvas 让浏览器不仅仅只是浏览器；ES6标准的确立，TypeScript，基于TypeScript的AtScript；基于shadow dom的webcomponets将web组件化推到了一个新的高度；ReactJ带来的virtual dom概念以及推倒MVC模式的FLUX模式，以及angular2.0带来的革命性变更；React Native让移动端web不再只局限于套浏览器壳子的Hybird app。。。。

前端这两年发展速度之快已经不能单单一哦那个飞速可以形容了，各种新的概念及技术被提出，光是各种名词就已经到了记都记不过来的程度了更别说都有所了解。前端开发再也不是以前那种写几个html标签写几行if else的刀耕火种的蛮荒时代。用 苏宁前端架构师 @民工精髓 的话说，前端发展已经由农耕时代进入到了第一次工业革命 蒸汽机时代了。对于前端而言，这是最混乱的时代，也是最好的时代。

是的，《前端已不止于前端》是一个只关注前端届最前沿**及技术的系列。

最后，用一句目前在前端届流传很广的“名言”来开启我们的篇章：

任何能用javascript实现的软件及系统，最终都会拿来用javascript实现。 －－ 马云

Angular黑科技之transclude

原文写于 2015-01-28

tansclude是angular生造的一个单词，不要去google啥意思相信我查不出来的。。。至于tranclude怎么翻译这件事我也是很懊恼，暂且将它译做 "隔离嵌入" 吧。具体含义大家在看过blog后自己体味吧。。。

transclude是angular指令中的一个配置，具体解释看这里

Extract the contents of the element where the directive appears and make it available to the directive. The contents are compiled and provided to the directive as a transclusion function. See the Transclusion section below.
There are two kinds of transclusion depending upon whether you want to transclude just the contents of the directive's element or the entire element:
true - transclude the content (i.e. the child nodes) of the directive's element.
'element' - transclude the whole of the directive's element including any directives on this element that defined at a lower priority than this directive. When used, the template property is ignored.

简言之就是将指令元素内部的节点内容在指令内部变得可用，不受指令隔离作用域影响。
使用场景一般是这样的：
我们需要封装一个组件，该组件有公用的header等区域，同时还有一个可以供使用者自由发挥的div区域。但是作为一个合格的angular开发者我们需要时刻关注自己的指令是否污染上层scope，所有大多情况下我们会使用隔离scope的做法。但是这个时候带来的问题是在隔离scope下我们的自定义div无法顺利的访问到自己作用域内容。这个时候我们需要在自定义指令中提供一个沙箱环境用于装载自定义div，这一块区域不受指令隔离scope影响。通常情况下我们会配合使用ng-transclude实现我们的需求，像下面这样
directive.transclude

.directive("todo", function(){

    return {
        restrict:"E",
        transclude:"true",
        template:"<header>{{header}}</header><div><span>这里是自定义区域</span><ng-transclude></ng-transclude></div>"
        scope:{
            header:"@"
        }
    };
})

调用时这样写
todo

<script>
    $scope.todo = “该干活啦!”;
</script>
<div>
    <todo header="todo list">
        <div>
            <span ng-bind="todo"></span>
        </div>
    </todo>
</div>

页面最后呈现的结果是这样的

<todo>
    <header>todo list</header>
    <div>
        <span>这里是自定义区域</span>
        <ng-transclude>
            <div>
                <span ng-bind="todo">该干活啦!</span>
            </div>
        </ng-transclude>
    </div>
</todo>

todo信息的展示不受指令的隔离作用域影响(隔离作用域中没有todo属性)

如果你以为我这篇仅仅是介绍下ng-transclude就完了。。。怎么可能区区ng-transclude官方文档都能查到demo的东西我会叫他黑科技？！！！没错接下来重点来啦！

ng-transclude这里正常的显示了指令外层作用域的内容是因为我这里只是做简单的读数据，如果我要写数据呢？假如我们有这样一个需求，当我们在transclude的内容里做的操作要影响外层展示，比如这样

<script>

    $scope.todo = “该干活啦!”;
</script>
<div ng-controller>
    <span ng-bind="todo"></span>
    <todo header="todo list">
        <div>
            <button ng-click="todo='休息时间!'"></button>
            <span ng-bind="todo"></span>
        </div>
    </todo>
</div>

<!-- 页面编译完成这样 -->
<div ng-controller>
    <span ng-bind="todo">该干活啦!</span>
    <todo header="todo list">
        <header>todo list</header>
        <span>这里是自定义区域</span>
        <ng-transclude>
            <div>
                <button ng-click="todo='休息时间!'"></button>
                <span ng-bind="todo">该干活啦!</span>
            </div>
        </ng-transclude>
    </todo>
</div>

当我们点击按钮时内层跟完成的todo信息会变成 "休息时间!" 么？
答案是 内层的会变，外层的不会。

原因就在ng-transclude。ng-tranclude是angular自己实现的一个指令，他的作用域继承自自定义指令外层的scope，所以我们在读取外层scope内容时没问题，但当我们尝试改写外层scope的属性时，实际上发生的是在ng-transclude作用域会生成一个相应的属性(比如上文的todo)，即 ngTranscludeScope.todo = "休息时间!" ，而ngControllerScope.todo依然为"该干活啦!"。

既然ng-transclude存在这样的问题那么我们改怎么解决不能写操作的问题呢？
好在angular为指令提供了一个transcludeFn的接口，它来自angular框架对指令内嵌内容编译后返回的链接函数，获取这个函数有几个方式

1. 指令controller注入

   return {
       transclude:true,
       controller:["$transclude",function($transclude){
   
       }]
   };

2. 指令compile时自动注入

   // 这种方式不推荐，因为transcludeFn通常需要依赖scope
   return {
       transclude:true,
       compile:function(element,attr,transcludeFn){
   
       }
   };

3. 指令link时自动注入

   return {
       transclude:true,
       link:function(scope,element,attr,controller,transcludeFn){
   
       }
   };

   transcludeFn调用方式如下：
   transcludeFn(scope, cloneLinkFn, futrueElement),看官方声明
   function([scope], cloneLinkingFn, futureParentElement).

   • scope: optional argument to override the scope.
   • cloneLinkingFn: optional argument to create clones of the original transcluded content.
   • futureParentElement:
     • defines the parent to which the cloneLinkingFn will add the cloned elements.
     • default: $element.parent() resp. $element for transclude:'element' resp. transclude:true.
     • only needed for transcludes that are allowed to contain non html elements (e.g. SVG elements) and when thecloneLinkinFn is passed, as those elements need to created and cloned in a special way when they are defined outside their usual containers (e.g. like <svg>).
     • See also the directive.templateNamespace property.

我们这里这样去用

.directive("todo", function(){

    return {
        restrict:"E",
        transclude:"true",
        template:"<header>{{header}}</header><div><span>这里是自定义区域</span><ng-transclude></ng-transclude></div>"
        scope:{
            header:"@"
        },
        link:function(scope,element,attr,controller,transcludeFn){
            transcludeFn(scope.$parent, function(transcludeContent, scope){
                element.find("ng-transclude").replaceWith(transcludeContent);
            });
        }
    };
})

我们通过transcludeFn将自定义指令内的节点的作用域手动指定为当前指令的父级作用域，然后将编译好的模板替换到ng-transclude层。
但是这样写有两个问题：

1. ng-transclude指令编译过一次模板，我们这里又手动编译了一次，出现重复编译
2. transcludeFn时我们通过element.find方式找到ng-transclude层，然后手动替换了模板。这种手动操作dom的方式违背了angular的理念

更优雅的做法是这样的

.directive("todo", function(){

    return {
        restrict:"E",
        transclude:"true",
        template:"<header>{{header}}</header><div><span>这里是自定义区域</span><content-transclude></content-transclude></div>"
        scope:{
            header:"@"
        },
        controller:["$transclude",function(transcludeFn){
            this.transcludeFn = transcludeFn;
        }]
    };
})

.directive("contentTransclude",funtion(){
    return {
        restrict:"E",
        require:"^todo",
        link:function(scope,element,attr,todoController){
            todoController.transcludeFn(scope.$parent, function(transcludeContent){
                element.append(transcludeContent);
            });
        }
    };
})

todo指令只提供一个维护transcludeFn的controller，然后新建一个contentTransclude指令调用父级controller的服务将沙箱内容插入到具体位置。这样各区块职责划分更明确，复用性更强，而且整个代码看上去更优雅了。

总结来看，就是transclude提供一个内联function可以让我们给沙箱区域手动指定任意作用域，而不是交由框架自动生成。在我看来这种能控制一切的东西简直就是黑科技！！

前端已不止于前端－ReactJs初体验

原文写于 2015-04-15

要说2015年前端届最备受瞩目的技术是啥，当然非ReactJs莫属。作为一个只关注最前沿前端技术的系列，自然少不了关于它的介绍。

ReactJs简介

• React最初来自Facebook内部的广告系统项目，项目实施过程中前端开发遇到了巨大挑战，代码变得越来越臃肿且混乱不堪，难以维护。于是痛定思痛，他们决定抛开很多所谓的“最佳实践”，重新思考前端界面的构建方式，于是就有了React。
• React的设计依托于Facebook另一个叫做FLUX的项目，FLUX是一个为了解决Facebook在MVC应用中碰到的工程性问题而生的设计模式，主要思路是单向数据流。解析 Facebook 的 Flux 应用架构
• React是MVC中薄薄的一层V，它只关注表现层，对组件化开发有很大的裨益。

ReactJs核心特征

• virtual dom react中的组件跟页面真实dom之间会有一层virtual dom(虚拟dom)，virtual dom是内存中的javascript对象，它具有与真实dom一致的树状结构。开发者每次试图更新view，react都会重新构建virtual dom树，然后将其与上一次virtual dom树作对比，依靠react强劲的核心算法dom diff找出真正发生变更的节点，最后映射到真实dom上，这也是react号称性能高效的秘密所在。依赖于virtual dom，对React而言，每一次界面的更新都是整体更新，而不是层叠式更新(即一个复杂的，各个UI之间可能存在互相依赖的时候，每一次独立的更新可能会引发其他UI的变化，假如我们的目的是更新C的数据，逻辑流很可能是这样的 A -->B-->C-->A-->B–>C，这种情况下中间状态的DOM操作就是极大的浪费)。
• 单向数据流 flux架构下的数据流呈现出一种单向、闭环的流动路线，使得一切行为变的可预测，也能更好的定位错误发生点。react官方的卖点之一就是 友好的错误提示(这是在针对angular么哈哈)
• 每个组件都是状态机 react认为组件的数据模型是不可变的，组件的属性不应该被修改。组件关注的只应该是状态，不同的状态呈现不同的表现形式。每个状态下的组件都是一个virtual dom对象，这样react就能直接通过等号对比对象地址判断组件是否被修改从而是否需要更新dom，这也是其能提高性能的原因之一(空间换时间)。
• 组件 一切都是组件 react倡导开发者将view切分成一个个组件从而达到松耦合及重用的目的。开发者构建页面只需要排列组合就行了。
• immutable object React提倡使用只读数据来建立数据模型，每次更新都是new object，这也是dom diff 性能强劲的密码所在(===即可判断两个对象是否相等，而不需要深度遍历)。参考资料 immutable.js
• JSX 不是在js里面写html，jsx是xml的javascript表示法。

说了这么多理论性的东西，还是直接来上代码吧

1. ReactJs开发准备工作

   1. 首先你需要reactjs的开发环境。

      bower install react

   2. 脚本中引入react，由于我们需要使用jsx语法提高开发效率，所以还需要引入能讲jsx转化为javascript的库
      不过这样JSXTransformer每次都会在app打开的时候做转换工作，并不适合生产环境，转换工作应该放在服务端进行，借助jsx工具

      npm install -g react-tools
      jsx --watch src/ build/

      然后页面依赖改成这样
      node插件会在你开发的时候自动将源码转成javascript文件到指定目录

2. 第一个react程序

   // Hello World
   React.render(
       <h1>Hello, world!</h1>,
       document.getElementById('example')
   );

3. 接下来我们介绍一下react的一些基础语法

   1. React.render() 将模版转换成html并插入到指定节点 参见上文的hello world示例

   2. React解析引擎的规则就是遇到<符号就以jsx语法解析，遇到{就以javascript语法解析。比如这样

      var array = [
          <h1>Example 2</h1>,
          <h2>Hello World</h2>
      ];
      
      React.render(
          <div>{array}</div>,
          document.getElementById("example2")
      );

      通过查看转换后的代码，我们可以看到他摘下面具后长这样

      var array = [
          React.createElement("h1", null, "Example 2"),
          React.createElement("h2", null, "Hello World")
      ];
      
      React.render(
          React.createElement("div", null, array),
          document.getElementById("example2")
      );

   3. 如何创建组件

      var HelloWorldComponent = React.createClass({
          render: function () {
              return <div>React Component {this.props.author}</div>;
          }
      });
      
      React.render(
          <HelloWorldComponent author="Kuitos"/>,
          document.getElementById("hello")
      );

      通过React.createClass可以创建一个关联了虚拟dom的组件对象，每次组件数据更新便会调用组件的 render 方法重新渲染dom。

   4. 组件对象的props属性
      上面一个例子我们看到在组件render方法中我们可以通过this.props.xx的方式拿到组件上关联的属性。另外需要额外提到的是，this.props有一个特殊属性children，它指向组件的子节点集合，like this

      var List = React.createClass({
          render: function () {
              return (
                  <ol>
                      {
                          this.props.children.map(function (child) {
                              return <li>{child}</li>
                          })
                      }
                  </ol>
              );
          }
      });
      
      React.render(
          <List>
              <a href="#">百度</a>
              <a href="#">谷歌</a>
          </List>,
          document.getElementById("example3")
      );

      页面渲染的结果就是一个 ol 列表中还有两个li，每个li中包含一个超链接。通过这里我们也可以看出，在jsx中｛｝是会getValue的

   5. 获取真实dom React.findDOMNode()

      var counter = 0;
      var Button = React.createClass({
      
          handleClick: function () {
              React.findDOMNode(this.refs.input).focus();
          },
      
          render: function () {
      
              return (
                  <div>
                      <input type="text" ref="input"/>
                      <input type="button" value="counter" onClick={this.handleClick}/>
                  </div>
              );
      
          }
      });
      
      React.render(
          <Button />,
          document.getElementById("button")
      );

   6. 组件状态 this.state

      var Toggle = React.createClass({
      
          getInitialState: function () {
              return {liked: false};
          },
      
          handleClick: function (event) {
              this.setState({liked: !this.state.liked});
          },
      
          render: function () {
      
              var text = this.state.liked ? "like" : "unlike";
      
              return (
                  <p onClick={this.handleClick}>
                      U {text} this.
                  </p>
              );
          }
      });
      
      React.render(
          <Toggle />,
          document.getElementById("button1")
      );

   7. 用React的方式实现angular中双向绑定的效果

      var Input = React.createClass({
      
          getInitialState: function () {
              return {value: "Kuitos"};
          },
      
          handleChange: function (event) {
              this.setState({value: event.target.value});
          },
      
          render: function () {
      
              var value = this.state.value;
      
              return (
                  <div>
                      <p>{value}</p>
                      <input type="text" value={value} onChange={this.handleChange}/>
                  </div>
              );
          }
      });
      
      React.render(
          <Input/>,
          document.getElementById("inputDataBind")
      );

   8. virtual dom状态变更回调

      组件生命周期分为三个状态：

      • Mouting: 已插入真实 DOM
      • Updating: 正在被重新渲染
      • Unmounting: 已移出真实 DOM
      • React为每个状态都提供相应的pre跟post处理函数。只不过React的命名是will(pre 进入状态之前)跟did(post 进入状态之后)。
      • componentWillMount()
      • componentDidMount()
      • componentWillUpdate(Object nextProps, Object nextState)
      • componentDidUpdate(Object prevProps, Object prevState)
      • componentWillUnmount()
        我们这样写

      var Input = React.createClass({
      
          getInitialState: function () {
              return {firstName: "Kuitos", lastName: "Lau"};
          },
      
          handleChange: function (event) {
              this.setState({firstName: event.target.value});
          },
      
          componentWillMount: function () {
              console.log("dom will be insert", this.state.firstName);
          },
      
          componentDidMount: function () {
              console.log("dom had be insert", this.state.firstName);
          },
      
          componentWillUpdate: function (nextProps, nextState) {
              console.log("dom will be update", nextProps, nextState);
          },
      
          componentDidUpdate: function (prevProps, prevState) {
              console.log("dom had be update", prevProps, prevState);
          },
      
          render: function () {
      
              var state = this.state;
      
              return (
                  <div>
                      <p>{state.firstName} {state.lastName}</p>
                      <input type="text" value={state.firstName} author={state.firstName} onChange={this.handleChange}/>
                  </div>
              );
          }
      });
      
      React.render(
          <Input/>,
          document.getElementById("inputDataBind")
      );

      打印的顺序依次是，dom will be update , dom had be update
      当input输入时 dom will be update , dom had be update

react的基本知识就介绍到这里，后续我们会继续介绍react在实战项目中的应用及react native在移动端的表现力。

ES规范解读之自增操作符

几个月前，不知道什么缘由跟xx同学讨论了起js里自增操作符(i++)的问题，现将前因后果整理出来，传于世人😂

事情起源于这样一段代码

var i = 0;
i = i++;
console.log(i);

来，都来说说答案是啥？
结果是0
换一种形式，或许大家不会有多少疑问

var i = 0;
var a = i++;
console.log(a); // 0

没错，这也是我们初学自增操作符的经典例子，对这结果还有疑问请自觉面壁。。。
遥想当年学习自增操作符的口诀大致是，i++ 是先用后自增，++i 是先自增再用
那么按照这个思路，上面的代码解析流程应该是这样的

var i =0;
i = i;
i = i + 1;

可惜结果并不是这样的
按照犀牛书上的描述，后增量(post increment)操作符的特点是

它对操作数进行增量计算，但返回未作增量计算的(unincremented)值。

但是书上并没有告诉我们，先做增量计算再返回之前的值，还是返回之前的值再做增量计算。
对于这种疑问，我们只能求助ecmascript给出官方解释：

Postfix Increment Operator(后自增操作符)

The production PostfixExpression : LeftHandSideExpression [no LineTerminator here] ++ is evaluated as follows:

1. Evaluate LeftHandSideExpression.
2. Call GetValue(Result(1)).
3. Call ToNumber(Result(2)).
4. Add the value 1 to Result(3), using the same rules as for the + operator (see 11.6.3).
5. Call PutValue(Result(1), Result(4)).
6. Return Result(3).

从es上的算法描述，我们能够清晰的得知，后自增操作符是先自增赋值，然后返回自增前的值，这样的一个顺序。
到这里还不算完。
既然i=i++这种操作最后i还是为原始值，也就是这段代码不会有任何实际意义，那么js引擎有没有可能针对性的做优化，从而避免不必要的自增运算？(如果你用的是IDE，IDE会提示你这是一段无用的代码)
也就是说，我们如何确定，执行引擎一定做了两步操作：

1. i = i + 1; return iBeforeIncrease = 0;
2. i = iBeforeIncrease;

还是执行引擎可能会针对性的优化，只做一步操作：

1. i = iBeforeIncrease;

当我在想怎么去确定这一点时，xx给出了解决方案，用Object.observe()方法啊！！(该方法是ES7提案中的新api，不过chrome早早的实现了)

var obj = {i:0};
Object.observe(obj, function(changes){
    console.log(changes);
});
obj.i = obj.i++;

代码放到chrome中跑一下，可以看到，改变触发了两次，也就是i做了两次修改操作。
另外firefox中也提供了一个类似的api，Object.prototype.watch，有兴趣的同学可以试试用这个方式来验证一下。

顺便抖个机灵，自增操作是非原子性操作，是非线程安全的，多线程环境下共用变量使用自增操作符是会有问题的。

Apollo GraphQL 在 webapp 中应用的思考

简介

熟悉 Apollo GraphQL 的同学可直接跳过这一章，从 实践 一章看起。

GraphQL 作为 FaceBook 2015年推出的 API 定义/查询 语言，在历经了两年的发展之后，社区已相对发达和完善。对于 GraphQL 的一些基础概念，本文不再一一赘述，目前社区相关的文章已经很多，有兴趣的同学可以去 google，或者直接看GraphQL 官方教程 Apollo GraphQL Server 官方文档。

而 Apollo GraphQL 作为目前社区最流行的 GraphQL 解决方案提供商，提供了从 client 到 server 的一整套完整的工具链。在这里我也准备以 Apollo 为例，通过一步步搭建 Apollo GraphQL Server 的方式，来给大家展示 GraphQL 的特点，以及我的一些思考（主要是我的思考🤪）。

setup

创建基于 express 的 GraphQL server

// server.js
import express from 'express';
import { graphiqlExpress, graphqlExpress } from 'apollo-server-express';
import schema from './models';

const PORT = 8080;
const app = express();

...
app.use('/graphql', graphqlExpress({ schema }));
app.use('/graphiql', graphiqlExpress({
	endpointURL: '/graphql'
}));

if (process.env.NODE_ENV === 'development') {
	glob(path.resolve(__dirname, './mock/**/*.js'), {}, (er, modules) => modules.forEach(module => require(module).default(app)));
}

app.listen(PORT, () => console.log(`> Listening at port ${PORT}`));

执行 node server.js，这样我们就能启动一个 GraphQL server 了。

注意我们这里使用了 apollo-server-express 提供的 graphiqlExpress 插件，graphiql 是一个用于浏览器端调试 graphql 接口的 GUI 工具。服务启动后，我们在浏览器打开 http://localhost:8080/graphiql就可以看到这样一个页面

定义 API schema

我们在 server.js 中定义了这样一个 endpoint : app.use('/graphql', graphqlExpress({ schema }));

这里传入的 schema 是什么呢？它大概长这样：

import { makeExecutableSchema } from 'graphql-tools';
// The GraphQL schema in string form
const typeDefs = `
  type User { 
    id: ID!
    name: String
    age: Int
  }
  type Query { user(id: ID!): User }
  schema { query: Query }
`;

// The resolvers
const resolvers = {
  Query: { user({id}) { return http.get(`/users/${id}`)}}
};

// Put together a schema
const schema = makeExecutableSchema({
  typeDefs,
  resolvers
});

app.use('/graphql', graphqlExpress({ schema }));

这里的关键是用了 graphql-tools 这个库提供的 makeExecutableSchema 组合了 schema 定义和对应的 resolver。resolver 是 Apollo GraphQL 工具链中提出的一个概念，什么用呢？就是在我们客户端请求过来的 schema 中的 field 如果在 GraphQL Server 中有对应的 resolver，那么在返回数据时候，这些 field 就由对应的 resolver 的执行结果填充(支持返回 promise)。

客户端请求

这里借助 graphiql 面板的功能来发送请求：

看一下 http request payload 信息：

响应体：

也就是说，无论你是用你熟悉的 http lib 还是社区的 apollo client，只要按照 GraphQL Server 要求的既定格式发请求就 ok 了。

这里我们使用了 GraphQL 中的 variable 语法，事实上在这种需要传参的动态查询场景下，我们应该总是使用这种方式发送请求：即一个 static query + variable 的方式，而不是在运行时动态的生成 query string。这也是官方建议的最佳实践。

更复杂的嵌套查询场景

假设我们有这样一个场景，即我们需要取到 User Entity 下的 nick 字段，而 nick 数据并不来自于 user 接口，而是需要根据 userId 调用另一个接口取得。这时候我们服务端的代码需要这样写。

// schema
type User {
  id: ID!
  name: String
  age: Int
  nick: String
}

// resolver
User: {
  nick({ id }) {
    return getUserNick(id);
  }
}

resolver 的参数列表中包含了当前所在 Entity 已有的数据，所以这里可以直接在函数的入参里取到已查询出来的 userId。

看下效果：

服务端的请求：

可以看到，这里多出了查询 nick 的请求。也就是说，GraphQL Server 只有在客户端提交了包含相应字段的 query 时，才会真正去发送相应的请求。更多 resolver 说明可以看这里。

其他

在真实的生产环境中，我们通常会有更多更复杂的场景，比如接口的权限认证、分页、缓存、批量提交、schema 模块化等需求，好在社区都有相对应的一些解决方案，这不是本文的重点所以不在这里一一介绍了，有兴趣的可以去看下我之前写的 graphql-server-startkit，或者官方的 demo。

实践

如果你真实的使用过 Apollo GraphQL，你会经历如下过程：

1. 定义一个 schema 用于描述查询入口

   // schema.graphql
   type User {
       id: ID!
       name: String
       nick: String
       age: Int
       gender: String
   }
   type Query {
       user(id: ID!): User
   }
   schema {
       query: Query
   }
   

2. 编写 resolver 解析对应类型

   const resolvers = {
   	Query: {
   		user(root, { id }) {
   			return getUser(id);
   		}
   	},
   	User: {
   		nick({ id }) {
   			return getUserNick(id);
   		}
   	}
   };

3. 编写客户端请求代码调用 GraphQL 接口，通常我们会封装一个 get 方法

   function getUser(id) {
     // 以 axios 为例
     return axios.post('/graphql', { query: 'query userQuery($id: ID!) {↵	user(id: $id) {↵    id↵    name↵    nick↵  }↵}', operationName: "userQuery", variables: {id}});
   }

   如果你的项目中加入了静态类型系统，那么你的代码可能就会变成这样：

   // 以 ts 为例
   interface User {
     id: number
     name: string
     nick: string
     age: number
     gender: string
   }
   function getUser(id: number): User {
     return axios.post('/graphql', { query: 'query userQuery($id: ID!) {↵	user(id: $id) {↵    id↵    name↵    nick↵  }↵}', operationName: "userQuery", variables: {id}});
   }

写到这里你可能已经发现，不仅是 entity 类型定义，就连接口的封装，我们在服务端和客户端都重复了一遍（虽然一个用的 GraphQL Type Language 一个用的 TS）… 这还是最简单的场景，如果业务模型复杂起来，你在两端需要重复的代码会更多（比如类型的嵌套定义和 resolve）。这时候你可能会想起 DRY 原则，然后开始思考有没**有什么方式可以使得类型及接口定义能两端复用，或者根据一端的定义自动生成另一端的代码？**甚至你开始怀疑，到底有没有引入 GraphQL 的必要？

思考

GraphQL 作为一个标准化并自带类型系统的 API Layer，其工程价值我也不再过多广告了。只是在实践过程中，既然我们无法完全避免服务端与客户端的实体与接口定义重复（使用 apollo-codegen 可以避免一部分），而且对于大部分小团队而言，运维一个 productive nodejs system 实际上都是力有未逮。**那么我们是不是可以考虑在纯客户端构建一个类 GraphQL 的 API Layer 呢？**这样既可以有效的避免编码重复，也能大大的降低对团队的要求，可操作的空间也比增加一个 nodejs 中间层大得多。

我们可以回忆一下，通常对于一个前端而言，促使我们需要一个 API Layer 的原因是什么：

1. 后端接口设计不够 restful，命名垃圾，用的时候看见那个*一样的 url 就难受。
2. 后端同学只愿意写 microservice，提供聚合服务的 web api 被认为没有技术含量，不愿意写。你需要一个数据，他告诉你需要调 a、b、c 三个接口，然后根据 id 组装合并。
3. 接口返回的数据格式各种嵌套及不合理，不是前端想要的结构。
4. 接口返回的数据字段命名随意或者风格不统一，我有强迫症用这种接口会发疯。
5. 后端返回的 数据格式/字段名 一旦变了，前端视图绑定部分的代码需要修改。

通常情况下，碰到这些问题，你可能去跟后端同学据理力争，要求他们提供调用体验更良好设计更优雅的接口。没错这很好，毕竟为了追求完美去跟各种人撕（跟后端撕、跟产品撕、跟UI撕）是一个前端工程师基本的职业素养。但是如果你每天都被撕逼弄得心力交瘁，甚至是你根本找不到撕的对象（比如数据来源接口来着几个不同部门，甚至是一些祖传的没人敢动的接口），这些时候大概就是你迫切希望有一个 API Layer 的时候了。

如何在客户端实现一个 API Layer

其实很简单，你只需要在客户端把 Apollo Server 中要写的 resolvers 写一遍，然后配上一些性能提升手段（如缓存等），你的 API Layer 就完成了。

比如我们在src下新建一个 loaders/apis 目录，所有的数据拉取接口都放在这里。比如这样：

// UserLoader.ts
export interface User {
  id: number
  name: string
  nick: string
}

export default class UserLoader {
  
  async getUser(id: number): User {
    const base = await Promise.all([http.get('//xxx.com/users/${id}'), this.getUserNick(id)]);
    const user = base.reduce((acc, info) => ({...acc, ...info}), {});
    return user;
  }
  
  getUserNick(id: number): string {
    return http.get(`//xxx.com/nicks/${id}`);
  }
}

然后在你业务需要的地方注入相应 loader 调用接口即可，如：

import { inject } from 'mmlpx';
import UserLoader from './UserLoader';
// Controller.ts
export default class Controller {
  
  @inject(UserLoader)
  userLoader = null;
  
  async doSomething() {
    // ...
    const user = await this.userLoader.getUser(this.id);
    // ...
  }
}

如果你不喜欢依赖注入的方式，loaders/apis 层直接 export function getUser 也可以。

如果你碰到了上面描述的第 3、4 、5 三种问题，你可能还需要在这一层做一下数据格式化。比如这样：

async getUser(id: number): User {
  const base = await Promise.all([http.get('//xxx.com/users/${id}'), this.getUserNick(id)]);
  const user = base.reduce((acc, info) => ({...acc, ...info}), {});
  
  return {
    id: user.id,
    name: user.user_name, // 重命名字段
    nick: user.nick.userNick  // 剔除原始数据中无意义的层次结构
  };
}

经过这一层的数据处理，我们就能确保我们的应用运行在前端自己定义的数据模型之下。这样之后后端接口不论是数据结构还是字段名的变更，我们只需要在这一层做简单调整即可，而不会影响到我们上层的业务及视图。相应的，我们的业务层逻辑不再会直接对接接口 url，而是将其隐藏在 API Layer 下，这样不仅能提升业务代码的可读性，也能做到眼不见为净。。。

总结

熟悉 GraphQL 的同学可能会很快意识到，我这不过是在客户端做了一个简单的 API 封装嘛，并不能解决在 GraphQL 出现之前的 lots of roundtrips 及 overfetching 问题。但事实上是 roundtrip 的问题我们可以通过客户端缓存来缓解（如果你用的是 axios 你可能需要 axios-extensions ），而且 roundtrip 的问题其实本质上我们不过是将客户端的 http 开销转移到服务端了而已。在客户端与服务端均不考虑缓存的情况，客户端反而会少一个请求。。。overfetching 问题则取决于 backend service 的粒度，如果 endpoint 不够 micro，即便是 GraphQL，也会出现接口数据冗余问题，毕竟 GraphQL 不生产数据，它只是数据的搬运工。。。而如果 endpoint 粒度足够小，那么我在客户端 API 层多开几个接口（换成 Apollo 也要多写几个 resolver），一样可以按需取数据。服务端 API Layer 只有一个不可替代的优势就是，如果我们的数据源接口是不支持跨域或者仅内网可见的，那么就只能在服务端开个口子做代理了。另外一个优势就是，GraphQL Server 的 http 开销是可控的，毕竟机器是我们自己控制，而客户端的环境则不可控（受限于终端设备及网络环境，比如低版本浏览器或者低速网络，均会导致 http 开销的性能权重增大）。

可能有同学会说，服务端 API Layer 部署一次任何系统都可以共享其服务，而客户端 API Layer 的作用域只在某一项目。其实，如果我们把某一项目需要共享的 API Layer 打成一个 npm 包发布出去，不也能达到同样的效果吗，很多平台的 js sdk 不都是这个思路么（这里只讨论 web 开发范畴）。

在我看来，不论你是否会搭建一个服务端的 API Layer，**我们其实都需要有一个客户端 API Layer 从数据源头来保证客户端数据的模型统一及一致性，从而有足够的能力应对接口的变迁。**如果你考虑的再远一点，在 API Layer 服务的业务模型层，我们同样需要有一套独立的 Service/Model Layer 来应对视图框架的变迁。这个暂且按下不表，后面会再写篇文字来详细说一下我的思路。

事实上，对于大部分团队而言，客户端 API Layer 已经够用了，增加一层 GraphQL 并不是那么必要。而且如果没有很好的支持将客户端接口转换成 GraphQL Schema 和 resolver 的工具时，我们并不能很愉快的 coding，毕竟两端重复的工作还是有点多。

AngularJs 基础与进阶

原文写于 2014-07-02

原文
Angular最佳实践

Javascript异步流程控制之Promise(2)-Angular $q源码解读

原文写于 2015-01-27

接上一篇 Angular $q简介 ，这一篇我们就Angular对$q的代码实现来学习下Promise的实现原理及**
上篇讲到了Angular Promise的基本API，其中就典型的应用类似这样

Promise.then

var defer = $q.defer();

setTimeout(function (){
    defer.resolve(10);
},5000);
console.log("1");
defer.promise.then(function(a){
    console.log(a);
});
console.log("2");

// 打印的顺序是1,2,10
// 当我们依赖的数据会在一个异步的时间点返回时，我们需要使用resolve 跟 then 来配合

首先我们要明确一个概念就是js是单线程语言，一个时间只能有一个线程在执行。那么上面的执行流程自然就是： 启动定时器并往事件队列里加入一个回调函数 ---> 打印1 ---> 调用defer.promise.then方法 ---> 打印2 --->主线程空闲开始等5秒(实际会小于5s)执行回调 ---> 调用defer.resolve ---> 打印10
至于这中间究竟发生了上面，先来看看angular是怎样实现这两个方法的

1. Promise.then

   // Promise.then
   function Promise() {
   this.$$state = { status: 0 };
   }
   
   Promise.prototype = {
       then: function(onFulfilled, onRejected, progressBack) {
           var result = new Deferred();
   
           this.$$state.pending = this.$$state.pending || [];
           this.$$state.pending.push([result, onFulfilled, onRejected, progressBack]);
           if (this.$$state.status > 0) scheduleProcessQueue(this.$$state);
   
           return result.promise;
       },
   .........

   Promise构造函数原型上维护一个方法 then ，当一个promise对象调用该方法时会往自己的成员属性 $$state 上构建一个 pending数组，然后将生成的deferred跟成功、失败回调压入pending数组。
   拿上文的案例来看， defer.promise.then之后 defer.promise.$$state.pending = [[new Deferred(), function (a){console.log(a)}]];
   再来看看defer.resolve发生了什么

2. Deferred.resolve

   // Deferred.resolve
   Deferred.prototype = {
       resolve: function(val) {
           if (this.promise.$$state.status) return;
           if (val === this.promise) {
               this.$$reject($qMinErr(
                   'qcycle',
               "Expected promise to be resolved with value other than itself '{0}'",
               val));
           }
           else {
               this.$$resolve(val);
           }
   
       },
   
       $$resolve: function(val) {
           var then, fns;
   
           fns = callOnce(this, this.$$resolve, this.$$reject);
           try {
               if ((isObject(val) || isFunction(val))) then = val && val.then;
               if (isFunction(then)) {
                   this.promise.$$state.status = -1;
                   then.call(val, fns[0], fns[1], this.notify);
               } else {
                   this.promise.$$state.value = val;
                   this.promise.$$state.status = 1;
                   scheduleProcessQueue(this.promise.$$state);
               }
           } catch (e) {
               fns[1](e);
               exceptionHandler(e);
           }
       },
   ......

   核心方法是 Deferred.$$resolve , 上文中 defer.resolve(10) 之后会走到 scheduleProcessQueue(this.promise.$$state);

   // scheduleProcessQueue
   function scheduleProcessQueue(state) {
     if (state.processScheduled || !state.pending) return;
     state.processScheduled = true;
     nextTick(function() { processQueue(state); });
   }

   nextTick方法定义在这里

   // nextTick
   function qFactory(nextTick, exceptionHandler) {
     var $qMinErr = minErr('$q', TypeError);
     .....

   再往上看谁调用了qFactory

   // qFactory
   function $$QProvider() {
     this.$get = ['$browser', '$exceptionHandler', function($browser, $exceptionHandler) {
       return qFactory(function(callback) {
         $browser.defer(callback);
       }, $exceptionHandler);
     }];
   }

   没错就是我们使用的 $q 服务，也就是$q在初始化的时候会 生成 nextTick = function(callback) {$browser.defer(callback);}
   $browser.defer干了什么事？

   // $browser.defer
   self.defer = function(fn, delay) {
     var timeoutId;
     outstandingRequestCount++;
     timeoutId = setTimeout(function() {
       delete pendingDeferIds[timeoutId];
       completeOutstandingRequest(fn);
     }, delay || 0);
     pendingDeferIds[timeoutId] = true;
     return timeoutId;
   };

   没错，很简单，就是一个定时器。将定时器时间默认设置为0的意图很明显，使当前任务脱离主线程，在事件队列执行时再做处理，也就是所谓的defer延时
   回到 scheduleProcessQueue，被手动从主线程中移除的任务是 nextTick(function() { processQueue(state); });
   看看 processQueue 是干嘛的

   // processQueue
   function processQueue(state) {
     var fn, promise, pending;
   
     pending = state.pending;
     state.processScheduled = false;
     state.pending = undefined;
     for (var i = 0, ii = pending.length; i < ii; ++i) {
       promise = pending[i][0];
       fn = pending[i][state.status];
       try {
         if (isFunction(fn)) {
           promise.resolve(fn(state.value));
         } else if (state.status === 1) {
           promise.resolve(state.value);
         } else {
           promise.reject(state.value);
         }
       } catch (e) {
         promise.reject(e);
         exceptionHandler(e);
       }
     }
   }

   没错，这个就是Promise处理最核心的部位。当主线程执行完毕开始处理事件队列时，processQueue 开始执行， 它会将 state.pending 队列(没错，队列里的内容就是我们调用then()方法时一个个压入的)遍历然后依次调用
   假如有这样一段代码
   promiseO.then(funcA).then(funcB);
   那么执行后会发生这样一个变化

   promiseO.then(funcA) ---> promiseO.$$state.pengding = [[deferredA, funcA]]; return deferredA.promise;  
   deferredA.promise.then(funcB) ---> deferredA.promise.$$state.pending = [[deferredB, funcB]]; return deferredB.promise;  
   
   // 当各个promise被依次resolve了
   // 1. 首先是promiseO.resolve(10) ---> promiseO.$$state.value = 10;promiseO.$$state.status = 1;scheduleProcessQueue(promiseO.$$state);
   // 2. scheduleProcessQueue最后走到processQueue方法，会执行promiseO.$$state.pengding队列，这时候会执行 deferredA.resolve(funcA(promiseO.$$state.value))
   // 3. 假设funcA(promiseO.$$state.value)返回20，那么就是 deferredA.resolve(20)。这时候就又回到了步骤1
   // 依次执行后then链上所有方法均会执行

   then的核心**是它会往当前promise的pending队列中压入then链下一个promise对象的Deferred(promise=Deferred.promise),然后通过这种节点关系构成整个then链

   介绍完promise.then我们再来介绍一下$q.all([promises]).then(funcT)，来看看他是怎么实现当所有promise被resolve之后再走向下一步的吧

3. $q.all

   // $q.all
   function all(promises) {
     var deferred = new Deferred(),
         counter = 0,
         results = isArray(promises) ? [] : {};
   
     forEach(promises, function(promise, key) {
       counter++;
       when(promise).then(function(value) {
         if (results.hasOwnProperty(key)) return;
         results[key] = value;
         if (!(--counter)) deferred.resolve(results);
       }, function(reason) {
         if (results.hasOwnProperty(key)) return;
         deferred.reject(reason);
       });
     });
   
     if (counter === 0) {
       deferred.resolve(results);
     }
   
     return deferred.promise;
   }

   很简单，forEach promises列表之后，在每个promise的then链加一个回调，关键代码在这一行
   if (!(--counter)) deferred.resolve(results);
   每一个promise成功执行了then回调之后会--counter,如果某个promise是最后一个被resolve的则将所有的results resolve，这个时候他的then链就开始执行了

4. $q.when

   //$q.when
   var when = function(value, callback, errback, progressBack) {
     var result = new Deferred();
     result.resolve(value);
     return result.promise.then(callback, errback, progressBack);
   };

   $q.when(val/promiseLikeObj)的用处很简单，就是将一个简单对象/或promiseLike的对象包装成$q信任的promise对象并将值加入到then链中。

写在最后：

至此$q的几个基本api都基于源码做了简单介绍，个人在研究源码的过程中最大的收获就是对js的异步模型有了更深刻的理解，并对工程化应用有了感官的认识，强烈建议有兴趣的同学读读源码。Promise是一种异步编程模型，是当前被普遍认可的一种解决方案，目前业界还有一些其他的异步解决方案诸如 thunk、co 模型等，思路各有差异跟优缺点，有兴趣的同学可以去了解相信会对你理解js的异步模型有进一步认识。

PS:
下一篇会介绍一下ES6中的Promise的api用法，敬请期待

web开发启示录(不定期更新)

原文写于 2015-05-27
web开发启示录

前端黑魔法之js加密

原文写于 2014-12-25

基于gulp的一个node插件，简直碉堡了啊。。那加密出来的东西都什么鬼哈哈哈哈哈
具体看文章

SpringMVC注解之@responsebody

原文写于 2013-04-18

web项目中会大量用到ajax请求实现前后台交互，以前处理后台返回给前台的集合数据的方式是这样的：

@RequestMapping("loadConfigUsers")
public void loadConfigUsers(String domain, HttpServletResponse response) {
    response.setCharacterEncoding("UTF-8");
    response.setContentType("text/html;charset=utf-8");
    List<Map<String, Object>> list = userConfigService.loadConfigUsers(domain);
    PrintWriter out = null;
    try {
        out = response.getWriter();
        out.print(JackSonMapper.toJsonString(list));
    } catch (IOException e) {
        logger.error("I/O出错", e);
    } finally {
        try {
            out.close();
        } catch (Exception e) {
            logger.error("关闭流出错", e);
        }
    }
}

也就是使用jackson将List<Map<String,Object>>对象转换为json格式的数组，如[{"a":"b"},{"c","d"}]。
有了@responsebody之后我们的代码就简单多了

@ResponseBody
@RequestMapping("loadConfigUsers")
public List<Map<String,String>> loadConfigUsers(String domain, HttpServletResponse response) {
    return userConfigService.loadConfigUsers(domain);
}

前台接收到的即为json格式数组，如[{"a":"b"},{"c","d"}]。SpringMVC底层会使用jackson将带有@responsebody的方法体的返回值转成标准的json格式。
想返回Map<String,String>格式的也一样

@ResponseBody
@RequestMapping("loadConfigUsers")
public Map<String,String> loadConfigUsers(String domain, HttpServletResponse response) {
    return userConfigService.loadConfigUsers(domain);
}

返回的json格式为 {"a":"b","c":"d"}。
也可以直接向前台返回String

@ResponseBody
@RequestMapping("loadConfigUsers")
public String loadConfigUsers(String domain, HttpServletResponse response) {
    return "success";
}

前台接收到的为 "success"。
但是在实际开发中碰到一个问题，返回List，Map，即前台接收到的为json格式字符串的时候中文字符都正常，但是直接返回String却会出现中文乱码问题。google一下发现SpringMVC是这样实现的。
SpringMVC对于注有@responsebody注解的方法返回值有自己的一系列转换器，当发现返回值为List，Map等集合类型时SpringMVC使用的是MappingJacksonHttpMessageConverter转换器，改转换器字符集设置的为UTF-8，附部分代码

public class MappingJacksonHttpMessageConverter extends AbstractHttpMessageConverter<Object> {
    // 设置默认字符集
    public static final Charset DEFAULT_CHARSET = Charset.forName("UTF-8");
    private ObjectMapper objectMapper = new ObjectMapper();
    private boolean prefixJson = false;
    /**
     * Construct a new {@code BindingJacksonHttpMessageConverter}.
     */
    public MappingJacksonHttpMessageConverter() {
        super(new MediaType("application", "json", DEFAULT_CHARSET));
    }
}

而对于返回值为String时使用的转换器则为StringHttpMessageConverter

public class StringHttpMessageConverter extends AbstractHttpMessageConverter<String> {
    // 设置默认字符集
    public static final Charset DEFAULT_CHARSET = Charset.forName("ISO-8859-1");
    private final List<Charset> availableCharsets;
    private boolean writeAcceptCharset = true;
    public StringHttpMessageConverter() {
        super(new MediaType("text", "plain", DEFAULT_CHARSET), MediaType.ALL);
        this.availableCharsets = new ArrayList<Charset>(Charset.availableCharsets().values());
    }
}

可以发现，两个转换器用的字符集竟然不一样，这个实在是难以理解，为毛用于处理同一个注解的两个转换器要用两种字符集？？
经过一番google及测试，发现了有一种方式是可以解决StringHttpMessageConverter字符集的问题，即修改我们的springmvc-servlet.xml，在<mvc:annotation-driven />前加上这样一段配置

<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping" />

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter" />

<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter">
    <property name="messageConverters">
        <list>
            <bean class="org.springframework.http.converter.StringHttpMessageConverter">
                <property name="supportedMediaTypes">
                    <list>
                        <value>text/plain;charset=UTF-8</value>
                    </list>
                </property>
            </bean>
            <bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter" />
        </list>
    </property>
</bean>

<mvc:annotation-driven />

即设置StringHttpMessageConverter可支持的媒体类型仅只有"text/plain;charset=UTF-8"一种。
另外还有一种是配置AnnotationMethodHandlerAdapter的messageConverters，即

<bean class="org.springframework.web.servlet.mvc.method.annotation.AnnotationMethodHandlerAdapter">       
    <property name="messageConverters">
            <list>
                <bean class="org.springframework.http.converter.StringHttpMessageConverter">
                    <property name="supportedMediaTypes">
                        <list>
                            <value>text/plain;charset=UTF-8</value>
                        </list>
                    </property>
                </bean>
                <bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter" />
            </list>
     </property>
</bean>

这种方式是将spring所有的messageConverters改为两种StringHttpMessageConverter、MappingJacksonHttpMessageConverter
使用这种配置就不能再用mvc:annotation-driven了，官方文档是这样写的。也就是说它会覆盖之前的配置

The above registers a RequestMappingHandlerMapping, a RequestMappingHandlerAdapter, and an ExceptionHandlerExceptionResolver (among others) in support of processing requests with annotated controller methods using annotations such as @RequestMapping , @ExceptionHandler, and others
This is the complete list of HttpMessageConverters set up by mvc:annotation-driven:
ByteArrayHttpMessageConverter converts byte arrays.
StringHttpMessageConverter converts strings.
ResourceHttpMessageConverter converts to/from org.springframework.core.io.Resource for all media types.
SourceHttpMessageConverter converts to/from a javax.xml.transform.Source.
FormHttpMessageConverter converts form data to/from a MultiValueMap<String, String>.
Jaxb2RootElementHttpMessageConverter converts Java objects to/from XML — added if JAXB2 is present on the classpath.
MappingJackson2HttpMessageConverter (or MappingJacksonHttpMessageConverter) converts to/from JSON — added if Jackson 2 (or Jackson) is present on the classpath.
AtomFeedHttpMessageConverter converts Atom feeds — added if Rome is present on the classpath.
RssChannelHttpMessageConverter converts RSS feeds — added if Rome is present on the classpath.

至于spring是如何选择可用的converter的，这里有一篇文章，有兴趣可以看下：这里

15年年末写了篇关于BEM方法论(实践上内容并不是原BEM)的文章，文末给自己挖了个坑说要聊聊Web语义化，跳票至今😂。16年第一篇用来填坑好了！

什么是语义化

The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries. --Wikipedia

语义化Web具备让数据跨终端共享／重用的能力。

对于HTML体系而言，Web语义化是指使用语义恰当的标签，使页面有良好的结构，页面元素有含义，能够让人和机器都容易理解。

语义化说起来好像都懂，但是实际情况并不是那么乐观。

再谈各种所谓的CSS设计模式

• OOCSS (Object Oriented CSS)

  ...a CSS “object” is a repeating visual pattern, that can be abstracted into an independent snippet of HTML, CSS, and possibly JavaScript. That object can then be reused throughout a site. — Nicole Sullivan

  <div class="item">
    <ul class="item-list">
      <li class="item-list--item">
        <h3 class="item-heading">...
  
  <button class="button button-primary">primary</button>
  <button class="button button-info">info</button>

  目标：

  • 减少对HTML结构的依赖
  • 增加CSS class重复性的使用

• SMACSS(Scalable and Modular Architecture for CSS)

  ...an attempt to document a consistent approach to site development when using CSS. — SMACSS

  <div class=“container”>
      <div class=“container-header”>
          <div class=“container-header__title”>
              <h1 class=“container-header__title--home”>

  一种css架构风格

• BEM(Block,Element,Modular)

  The BEM approach ensures that everyone participating in the development of a website is working with the same codebase and using the same terminology — BEM Methodology

  <ul class="menu">
      <li class="menu__item">...</li>
      <li class="menu__item_state_current">...</li>
      <li class="menu__item">...</li>
  </ul>   

  与SMACSS类似

• METACSS | ATOMCSS (原子CSS)

  <div class="fl mr10 red">
      <span class="blue fl"></span>   
  </div> 

• WTFSS

为什么会有这么多层出不穷(千奇百怪)的CSS设计模式

Cascading Style Sheets (CSS) are a stylesheet language used to describe the presentation of a document written in HTML or XML (including XML dialects like SVG or XHTML). CSS describes how elements should be rendered on screen, on paper, in speech, or on other media. －－MDN

1. CSS本身的不足，不具备逻辑表达能力 & 抽象能力
2. We had to maintain a shit。。。所以我们需要更有效的去减少让自己恶心的成本。。

但这些都只是部分客观原因，主要原因在于我们对于Web语义化的理解度不够以及非正确的工作流。

以表现为中心(面向UI) VS 以信息为中心(面向语义)

以表现为中心的工作流： 需求原型 --> UI设计稿 --> 以HTML／CSS实现设计稿

以信息为中心的工作流： 需求原型 --> 分析需求并以HTML描述 --> UI设计稿 --> 分析样式并以CSS实现

两者最大的区别在于，对于面向UI的工作流而言，HTML／CSS只是实现UI的手段，而对于纯正的Web开发(面向语义的工作流)而言，我们应该是以信息为中心的，即首先考虑信息的本质(语义)，并以合适的标签来标记，最后再考虑样式和行为(UI)。

之所以会有那么多层出不穷(不知所谓)的CSS设计模式，是因为它们大都是以表现为中心提出的“最佳实践”，而这两种方法论本身又是不适配的。

为什么说面向语义(以信息为中心)才是纯正的Web开发

1. Web诞生的目的是用于在网络上传递资源跟信息的。HTML设计之初是用来作为互联网上主要的内容载体，其本身是用来描述信息的。在最早期的Web时代，HTML作为一种通用的描述语言用来表述在互联网上传输／共享的文档的信息。
   Web 万维网

   The World Wide Web (WWW) is an open source information space where documents and other web resources are identified by URLs, interlinked by hypertext links, and can be accessed via the Internet.

   HTML 作为一种对计算机而言通用易懂的母语

   To publish information for global distribution, one needs a universally understood language, a kind of publishing mother tongue that all computers may potentially understand.

2. Web领域的一套基础架构跟技术（包括HTTP、REST、HTML等），是按照语义中心的方式设计出来的。如果采用UI中心的方法论，必然导致阻抗不匹配。

3. w3c官方也在致力于推广Web语义化

   • 各种表现型标签／属性在HTML5中被废弃／不推荐使用(center、big、width等)
   • HTML5中新增的各种语义化标签(header、nav等)，而这些标签在表现上跟div无二。

CSS语义化？

通常意义上我们说的CSS语义指的是class的语义。class作为HTML与CSS之间的主要钩子，却是被我们误解最深的一个东西。

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content. --w3c

class属性本意是用来描述元素内容的，而不是描述元素展现的。其典型‘反模式’代表就是METACSS。
看看这两段代码，哪一个更容易理解？

<!-- 以表现为中心 -->
<div class="fl mr10">
    <span>userName:Kuitos</span>
<div>

<!-- 以信息为中心 -->
<div class="user-info">
    <span>userName:Kuitos</span>
<div>

class作为HTML描述属性集的一部分，本身是用来细化内容语义的，所谓的CSS语义化本质上就是HTML语义化。

符合标准的最佳实践

在CSS领域发展的初期，严格意义上的“最佳实践”都是不存在的，这主要受制于CSS的支持度，大部分浏览器的CSS的支持不够好，所以也导致我们很难在表现及语义之间做平衡。所以我们在翻看HTML标签的时候会看到诸如<b><center>这类纯样式的历史性标签(这些标签已经不被HTML5 spec推荐使用)。

但是为什么到了CSS已经如此强大(且浏览器支持度也都挺好)的年代，依然会出现那么多实质还是以表现为中心提出的所谓“最佳实践”？其实，这归结起来，源于我们对于CSS复用的这种刚性需求。

以OOCSS为例，我们写一组按钮可能会这么写：

<button class="button-primary"></button>
<button class="button-error"></button>

.button-primary {
    width: 80px;
    height: 40px;
    background-color: green;
    ...
}

.button-error {
    width: 80px;
    height: 40px;
    background-color: red;
    ...
}

我不能每写一个button都重复一遍宽高啊，要复用，所以我们可能会把公共部分提取出来

<button class="button button-primary"></button>
<button class="button button-error"></button>

.button {
    width: 80px;
    height: 40px;
}

如果你秉承这个思路，当哪天产品要求第一个按钮要左排第二个要右排的时候，我估摸着你会很自然的这么去写：

<button class="button button-primary float-left"></button>
<button class="button button-error float-right"></button>

.float-left {
    float: left;
}
.float-right {
    float: right;
}

更甚者，哪天产品要求第二个按钮跟右边隔10像素，你会不会这么写？

<button class="button button-error float-right mr10"></button>

css我就不写了mr10什么意思我猜你已经知道了。。
且不说<button class="button button-primary"></button>这种写法中button本身就是一种冗余信息(我当没看见也罢)，mr10则基本上无法忍受了，仔细想想这跟直接写inline-style有什么差别？相反我写inline-style更符合标准，至少我是挂载在专门用于描述表现的style属性上面，而不是用来描述内容的class上面。

基于这样的一连串演进，最后大概会诞生出两个症状：

1. 样式类 即一系列诸如 mr10 fl之类的class
2. 多class症 即几乎每个元素上都要挂载至少一个class。

原因在于，如果我们需要达到复用的效果，最后必定会魔障出一条理念：样式需具备独立性与上下文无关，同时粒度需要够小(样式类／通用原子类)。

其中也有一个主要原因是我们对CSS的误解

css ＝ 层叠样式表，其关键词在层叠

“复用”需求最后一定会导致我们样式退化到平级的单class规则定义，因为这样才能足够无状态。但实际上CSS最独特的地方在于层叠，你避开这种机制从而来满足复用需求，最后不单单丧失了CSS的能力，反而会催生出一系列不符合语义化标准的反模式。

但是我也说过，复用是刚需，而CSS又不具备抽象能力，所以我们只能眼睁睁的看着一坨坨屎流行么？

好在我们有预处理器

最佳实践 Sass/Less

Sass/Less我这里就不一一赘述了，时至今日相比大家都很熟悉。为什么说最佳实践是Sass/Less呢？简单来说，就是这类预处理器在提供一定的抽象能力的同时，也不会破坏css自身的特性。拿上面的例子来看，如果我们使用Sass/Less的写法：

%button {
    width:80px;
    height:40px;
}

.button-primary {
    @extend %button;
    background-color: white;
}

.button-success {
    @extend %button;
    background-color: green;
}
.button-error {
    @extend %button;
    background-color: red;
}

如果我们在项目级别需要统一的配色，可以做进一步的抽象

$primary-bgc: white;
$success-bgc: green;
$error-bgc: red;
.button-primary {
    @extend %button;
    background-color: $primary-bgc;
}
.button-success {
    @extend %button;
    background-color: $success-bgc;
}
.button-error {
    @extend %button;
    background-color: $error-bgc;
}

同样的手段还有mixin。
我们可以将我们需要复用的“样式类”抽象成placeholder／mixin(对于“通用原子类”这样的需求我推荐用placeholder)，然后使用语义化的 class／属性 作为钩子，来组装这些“原子类”(但实际上这些“原子类”对CSS而言是不可见的)。比如我们用a标签来模拟一个提交按钮，我们应该这样写：

<a href＝"#" role="submit-button">提交</a>

a[role="submit-button"] {
    @include .button-success;
}

所以css的最佳实践应该是： Sass + OOCSS/BEM/METACSS

这里有一个关键点在于，我们在使用这些css抽象方法论来写sass的时候，切记不要把中间变量暴露给css。什么意思呢，button那个例子我这样来写

.button{
    width: 80px;
    height: 40px;
}
.button-primary {
    @extend .button;
}

此时button对于css而言是可见的。对于button这类抽象产物，我们应该用placeholder和mixin代替，确保其对css的不可见从而保证web的“纯度”。(这也是我不推荐Less的原因，Less最大的失误在于没有placeholder的设计)

到这里估计思考过的同学会有疑问：很多场景可能并没那么容易语义化，比如我要第一个元素左浮动，第二个元素右浮动，第三个又左浮动，第四个右浮动。。。

这里需要提到另一个经常被误解的点：selector。selector作为HTML与CSS的结合点，实质上也是需要语义化的。tag跟id是天生带语义的，主要问题还是出在class上。我们总是尝试在class上挂载一些表现型的“名称”。这里面有一小部分确实是由于CSS本身的不完美(比如layout这种场景细则就比较难语义)导致的，但是过多的则归咎于我们语义化动力不足及对selector的认知不够。语义化动力不足完全是主观因素这里不赘述，对selector认知不够则是最普遍存在的情况。推荐阅读：为后代选择器及id选择器辩护 结合智能选择器的语义化的CSS

为什么一定要按标准来？

其实我不太想回答这种问题。。。我更想反问：为什么不按标准来？！！

一定要说的话：

1. 推行标准的目的是为技术交流构建一个统一的上下文语境平台，提高沟通效率，避免鸡同鸭讲。
2. 同时标准跟规范的制定是经过一群 资深开发者／科学家 经过仔细研究及社区讨论的，一套完整的一致的基础架构系统是推进生态发展的必要条件。
3. 就Web语义化这件事情而言，如果你的HTML是基于标准来编写的，意味着你的页面具备更多的可能性。比如搜索引擎友好，多终端适配(不是响应式。。是指兼容各种阅读设备、读屏软件等。参见microformats)，更智能的风格查错能力。
4. 在前端开发体系里，能体系专业性的地方不多。。拿程序复杂度而言，它跟大型后端系统差不止一个量级(前端的难度在于工程上)。。好不容易有一个能体现专业素养的领域(语义化Web)，为什么我们不抓住机会为自己正名呢。。

推荐阅读：

1. http://hax.iteye.com/blog/497338
2. http://hax.iteye.com/blog/500015
3. http://hax.iteye.com/blog/849826

[译注] MVVM 模式

原文：The MVVM Pattern

MVVM 模式跟 Silverlight 这类 XAML 应用平台是天生合拍的。这是因为 MVVM 模式利用了Silverlight 的一些特殊能力，比如说 数据绑定，命令，行为等。MVVM 跟其他一些将表现及UI布局 与展示层逻辑的职责进行分离的模式很相似；如果你对 MVC 模式熟悉的话，你会发现它与 MVVM 之间存在很多相似的概念。

译者注：XAML(Extensible Application Markup Language)是微软为构建GUI程序而创建的一种标记语言，你可以将它等同于 web 体系中 HTML。以下译文中，web 开发者可以将 XAML 统一代入为 HTML。Silverlight 则是微软开发的一个 富互联网应用(Rich Internet Application) 开发平台。

MVVM 模式的设计动机

诸如 Windows Forms，WPF，Silverlight 以及 Windows Phone 这类开发技术都提供了一个默认的体验，那就是它可以让开发者从工具箱中拖拽控件到设计面板，然后在代码文件中编写一定格式的代码就能完成整个开发。但是随着这类应用的增长规模及作用范围的变化，复杂的维护性问题就会随之而来。由于 UI控件 与 业务逻辑 之间的紧耦合，相应带来的问题就是 UI 变更的代价增大，以及难以编写针对性的单元测试。

使用 MVVM 模式来实现应用的主要动机有以下几点：

1. 它提供了一系列分离的概念。紧耦合，难变化，脆弱的代码导致了各种各样的长期维护的问题，最后导致了客户对交付的软件较低的满意度。在应用逻辑及 UI 之间进行干净的分离将会让应用更容易测试，维护以及拓展。它提高了代码的重用性同时使得 开发-设计 的工作流变为可能。
2. 它与 XAML 平台是天生合拍的。MVVM 模式的关键推动力来自于 Silverlight 平台丰富的数据绑定技术栈及一些依赖属性。这些东西的组合提供了 UI 到 VM(译者注：view model 视图模型后面统一简称 VM) 之间的连接方式。
3. 它使得 开发-设计 的工作流成为可能。当 UI XAML 不是与代码紧耦合时，设计师们就很容易去自由的发挥他们的创造力，从而做出一个更优秀的产品。(译者：简单来说就是 视图层 跟 M/VM 层的开发可以是正交的。)
4. 它增强了应用的可测试性。将 UI 逻辑转移到一个可以独立实例化的类中，可以让单元测试的编写更加容易。(译者：这一点其实非常重要)

MVVM 模式

Model-View-ViewModel 的模式可以用到所有的 XAML 平台上。它的意图是在 UI 控件和它们的逻辑之间进行一个纯净的概念分离。

MVVM 模式中有三个核心的组件：model(模型)，view(视图) 以及 view-model(视图模型)(译者注：为保证交流中术语的一致性，model、view、view-model后面均不作翻译)，它们彼此间扮演一个截然不同的角色。下面的插图展示了这三个组件之间的关系：

每个组件之间都是相互解耦的，这也使得：

• 组件可以被交换
• 内部实现可以在不影响其他组件的情况下修改
• 组件可以独立的运作
• 隔离的单元测试

除了理解这三个组件的职责，理解组件之间是如何交互的也同样重要。在最高的层级上，view 能感知到 view-model，view-model 能感知到 model，但是 model 并不会察觉到 view-model 的存在，同样的，view-model 也察觉不到 view。

view-model 将 model 类 与 view 隔离开来，这也使得 model 可以独立于 view 进行演化。

View

view 的职责是用来定义 结构、布局，及用户在屏幕上看到的外观表现。理想情况下，view 仅通过 XAML 定义，以及一些有限的不包含业务逻辑的代码。

在一个 Windows Phone 应用中，view 通常是一个页面。除此之外，一个 view 也可以是一个父 view 的子组件，或者一个 ItemsControl 中的 DataTemplate对象。

一个 view 可以有自己的 view-model，或者继承自父级 view 的 view-model。**视图通过绑定，或者调用 view-model 上的方法来获取数据。**在运行期间，UI 控件将会响应 view-model 属性触发的变化通知，从而改变 view。

有一些 view 上的交互会触发 view-model 上的代码执行，比如说按钮点击或者选项选中事件。如果这个控件是一个命令源，这个控件的 Command 属性可以在 view-model 上绑定成一个 ICommand 属性。当这个控件的命令被调用，view-model 上相应的代码就会被执行。除了命令，行为也能被附加到 view 的一个对象中，然后监听命令调用及事件触发。作为回应，这个行为之后可以调用 view-mode 上的 ICommand 或者方法。(译者：web 领域里这些就是指的模板上的事件绑定语法，通常由框架提供)

Model

model 在 MVVM 中是应用的域模型(domain model)实现，它包含数据模型以及相应的业务和校验逻辑。model 对象的例子包括，数据仓库(repositories)，业务对象，数据转换对象(DTOs)，POCO对象，以及生成的实体及代理对象。

译者：一个 model 应该包含基本的模型数据、基本的业务逻辑、业务规则、数据转换、依赖校验逻辑等。这里要提到的一个概念就是，域模型分为两个类型，一类是贫血的(Anemic domain model)，一类是非贫血的(non-anemic)。贫血的域模型只包含基础的数据信息，而不含有其他数据校验、业务规则等逻辑，它更像是一种数据库结构在代码层面的还原。在贫血域模型设计中，业务逻辑通常作为一个独立的代码部分，用来转换模型对象的状态，且各个处理之间可以组合嵌套（用过Redux的同学有没有觉得很熟悉的感觉？）。在面向对象设计领域，这通常被视为一个反模式。（OO与FP之间的冲突）

View Model

view-mode 作为 view 和 model 的中间人，它的职责是用于处理 view 的逻辑。**通常情况下，view-model 与 model 之间的交互是通过调用 model 类中的方法来完成的。之后 view-model 依据 model 中的数据提供一种方便 view 使用的格式。**view-model 从 model 中获取数据然后使其对 view 可用的同时，为了让 view 操作起来更简单，可能会通过一些方式做数据格式转换。view-model 还提供了一些命令的实现让应用的用户可以在 view 中使用。比如说，当用户点击了 UI 中的一个 button，这个动作可以触发 view-model 中的一个命令。view-model 同样有职责去定义一些某些方面会影响 view 展示的逻辑状态的变化，比如说一个表明一些操作是挂起的状态。

为了让 view-model 参与到与 view 的双向数据绑定当中，它的属性必须触发 PropertyChanged 事件。

(译者注：后面这两段是基于 .NET 平台的具体代码实践，换算到 web 领域，基本上说的就是在 VM 中监听数据变化，然后做出对应的反应。)

View-model 通过实现 INotifyPropertyChanged 接口以及属性变化时触发的 PropertyChanged 事件来满足这个需求。当属性发生变更时，监听者可以适当做回应。

对于集合而言，相应的提供了视图友好的工具System.Collections.ObjectModel.ObservableCollection 。这个工具实现了集合变更通知，从而减轻了开发者自己在集合上实现 INotifyCollectionChanged 接口的负担。

译者：这里提到了一个很重要的事情，就是 vm 获取到 model 中的数据后，可能需要做一些相应的数据格式化，以方便 view 使用。在 ng1.x 及 vue1.x 中，这类操作通常是通过在视图模板上绑定过滤器语法实现的(ng-bind="model | upperCase")，然而 MVVM 定义中，数据转换/格式化 的操作本身也是属于 VM 的一部分。这也是为什么我非常赞同 vue2 中废除 filter 的一部分原因：Vue 2.0 - Bring back filters please

连接 View Models 到 Views

MVVM 利用了 Silverlight 中的数据绑定能力以及行为和事件触发器来管理 view 和 view-model 之间的联系。这些能力将业务代码需要出现在视图代码中必要性变得很低。

有很多用来连接 view-model 和 view 的方法，包括直接的关系以及基于容器的方式。然而，所有的方式共有的一个目标就是，给 view 的 DataContext 属性分配一个 view-model。

Views 可以与 view models 在独立代码文件里建立连接，也可以直接在 view 中。

译者：这里提到了 silverlight 里的 DataContext，换到 web 领域的 MVVM 框架里我们可以理解成作用域，即框架通过给某个视图的作用域分配一个 view-model 的方式，来完成 view 和 view-model 的衔接。

Code-Behind(独立代码)

一个 view 的代码可以是在独立代码文件中，于此同时 view-model 需要分配成它的 DataContext 属性。这可以是通过一个简单的 view 初始化一个新的 view-model 然后分配给它的 DataContext 属性来完成，也可以通过 view 使用控制反转(IOC)容器注入一个 view-model 来实现。

但是，在独立代码中 连接一个 view-model 到 view 中的做法是不推荐的，它可能给同时使用 VS 及 MSB(Microsoft Expression Blend®) 设计软件的设计师造成问题。

View

如果一个 view-model 没有任何的构造器参数，它可以被当做 view 的 DataContext 来实例化。一个通常的实现方法是使用一个 view-model 定位器。这个资源可以公开应用的 view models 作为属性，从而使得独立的 view 可以绑定上去。这种方式意味着应用只有一个类用来连接 view models 到 views。此外，它仍然让开发者可以自由选择手动执行 view-model 定位器内的连接，或者使用一个依赖注入容器。

译者：框架实现指导

MVVM 的优势

MVVM 使得完美的 开发-设计 工作流变为可能，它具备以下优点：

• 开发期间，工程师和设计师可以更独立并行的在各自的组件上工作。设计师可以专注于 view，如果他们使用 Expression Blend，他们可以轻松的生成示例数据，而这个时候开发者只需要专注于 view model 和 model 组件。
• 开发者可以为 view-model 和 model 编写单元测试，而不用去管 view。view-model 的单元测试可以完全模拟在 view 上用的那些功能。
• 由于 view 是完全由 XAML 实现的，这也让应用的 UI 重新设计变得简单，而且还不用去触碰到逻辑代码。一个新的版本的 view 应该依然可以与之前已存在的 view-model 一起运行。
• 如果已经存在一个封装好了已有业务逻辑的 model ，改这个 model 可能会比较困难或有风险。在这个场景中，view-model 应该作为一个 model 类的适配器，从而避免 model 的代码需要做大的变动。(译者注：也就是说，view-model 应该对 model 中的数据做一些基础转换，从而去适配新的 view 或交互逻辑)

更多关于 MVVM 的信息，参考以下文档： Implementing the MVVM Pattern Advanced MVVM Scenarios

译者按：

MVVM 作为2005年微软提出来的 UI 架构，我认为在经过这么多年的检验之后，还是非常值得信赖的。虽然在这一两年随着 React 的兴起，以及在前端领域“起死回生”的函数式编程，MVVM 被各种错误或‘恶意’的解读导致其花式被黑。但是在我看来，MVVM 作为一个完整的 GUI 架构，跟 Flux 流派的数据层架构本身理念上是并不冲突的。我们依然可以 M/VM 层实践 Flux。

我认为就前端领域而言，MVVM 最大的意义在于，如果我们能很干净的分离出应用的 view 和 M/VM，我们就可以使得整个应用的业务模型能独立于框架运行。相比于现在换一个框架就重写一次应用的做法(老实说我受够了而且觉得没什么价值)，再结合当前前端‘欣欣向荣’的状态，如果能做到只需要花费很小的代价，我们就能快速的享受到新技术带来的红利，那基本上就非常美好了。

Javascript单线程及定时器原理分析（1）

原文写于 2014-07-28

Talk is cheap, code first.

说出代码运行结果

var i,a=0;
setTimeout(function(){
    console.log("timeout");
}, 1000);
for(i=0;i<10;i++){
    a += i;
    if(i === 9){
        console.log("loop over");
    }
}

没错，当然是 loop over --> timeout
那么如果我们把timeout时间设为 0 呢，就像这样

// code1
setTimeout(function(){
    console.log("timeout");
}, 0);

结果还是 loop over --> timeout !!
我们假设你已经知道HTML5 spec定义了setTimeout最短时间间隔为4ms这个事实，但是浏览器实现的最短时间间隔一般是10ms。
这个时候你可能会说for循环先执行完且时间短于4ms,所以顺序是 loop over --> timeout.
假如我们把循环放大， 就像这样

// code2
for(i=0;i<1000000;i++){
    a += i;
    if(i === 999999){
        console.log("loop over");
    }
}

结果却还是 loop over --> timeout.
你可能会说 1000000 次循环时间小于4ms， 好吧我们假设chrome已经如此这般牛x.
那如果我们把完整代码改成这样呢

//code 3
var i,a=0,begin;
setTimeout(function(){
    console.log("timeout");
}, 1000);
console.log(begin=Date.now())
while(true){
    if(Date.now()-begin>1500){
        console.log("loop over");
        break;
    }
}
console.log(Date.now());
console.log("WTF!");

WTF！循环时间超过1000ms的情况下结果依然是 loop over --> WTF --> timeout !!
会出现这种结果的一起原因归结于 Javascript是单线程的，所以导致 javascript的定时器从来都不是可靠的，当JS引擎的线程一直很忙的时候，它的定时器是永远不会执行的。只有线程空闲下来的，才有功夫去玩你的定时器。看这段代码

// code4
var a = 0;
setTimeout(function(){
    console.log("timeout");
}, 1000)
while(true){
    a++;
}

没错，timeout永远都不会打印出来。（如果你不幸在浏览器中运行了这段代码，请调出进程管理器，kill process ....）。

假如你有过一定的js代码经验，你一定会问，既然是单线程的，那么javascript中的异步是怎么实现的呢，那些所谓的回调又是几个意思，用来装x的专业术语而已？

Javascript中的异步是基于 event-driver（事件驱动） 的，几乎所有的单线程语言都是通过这种方式实现异步的。什么是异步呢，言简意赅的说，异步函数就是会导致将来运行一个取自事件队列的函数的函数。

事件队列又是什么东西呢？？

我们举个例子说明，假设：我们处于一个页面，这个页面上有一个setTimeout正在执行延时1000ms执行某段代码；而在这个200ms的时候，我们点击了一个按钮，因为此时已经满足事件触发条件，且JavaScript线程空闲，所以按照我们的脚本浏览器会立即执行与这个事件绑定的另外某段代码；点击事件触发的某段代码会做两件事，一件事是注册一个setInterval要求每隔700ms执行某段代码；另一件是发送一个ajax请求，并要求请求返回后执行某段代码，这个请求会在1500ms后返回。在这之后，可能还会有其它的事件被触发。
那么在整个事件队列中，他是如下排列的：

这时候我们可以再来试着解释一下code3那段代码的执行机制是怎样的。
在此之前有一点你必须要明确，Javascript中函数是一等公民，所有代码块的运行都是基于函数的！
code4代码处于全局环境，所以我们可以将它一整个代码块理解成一个 立即执行的匿名函数， 就像这样

// code5
(function(){
var i,a=0;
setTimeout(function(){
    console.log("timeout");
}, 1000);
for(i=0;i<100000;i++){
    a += i;
    if(i === 99999){
        console.log("loop over");
    }
}
console.log("WTF!");
})();

那么js引擎解释这段代码时过程是这样的：

1. 发现一个匿名函数，将该函数加入到事件队列中。执行匿名函数
2. 执行到setTimeout方法，构建一个定时器，将定时器加入到事件队列中，此时队列顺序为： 匿名函数 --> 定时器回调
3. js引擎线程继续处理匿名函数，依次输出 loop over –> WTF
4. 匿名函数执行完毕，发现队列里还有一个定时器，于是执行定时器回调。

Angular1.x + ES6 开发风格指南

阅读本文之前，请确保自己已经读过民工叔的这篇blog
Angular 1.x和ES6的结合

大概年初开始在我的忽悠下我厂启动了Angular1.x + ES6的切换准备工作，第一个试点项目是公司内部的组件库(另有seed项目)。目前已经实施了三个多月，期间也包括一些其它新开产品的试点。中间也经历的一些痛苦及反复(组件库代码经历过几次调整，现在还在重构ing)，总结了一些经验分享给大家。(实际上民工叔的文章中提到了大部分实践指南，我这里尝试作一定整理及补充，包括一些自己的思考及解决方案)

开始之前务必再次明确一件事情，就是我们使用ES6来开发Angular1.x的目的。总结一下大概三点：

1. 框架的选型在这几年是很头痛的事情，你无法肯定某个框架会是终极解决方案。但是有一点毫无疑问，就是使用ES6来写业务代码是势在必行的。
2. 我们可以借助ES6的一些新的语法特性，更清晰的划分我们应用的层级及结构。典型的就是module跟class语法。
3. 同样的，在ES6语法的帮助下，我们能较容易的将数据层跟业务模型层实现成框架无关的，这能有效的提升整个应用的可移植性及演化能力。从另一方面讲，数据层跟业务模型能脱离view独立测试，是一个纯数据驱动的web应用应该具备的基本素质。

其中第1点是技术投资需要，第2、3点是架构需要。

我们先来看看要达到这些要求，具体要如何一步步实现。

Module

在ES6 module的帮助下，ng的模块机制就变成了纯粹的迎合框架的语法了。
实践准则就是：

1. 各业务层及数据层代码理想状态下应该看不出框架痕迹。
2. ng module最后作为一个壳子将所有的业务逻辑包装进框架内。
3. 每个ng module export出module name以便module之间相互引用。

example:

// moduleA.js 
import angular from 'angular';
import Controller from './Controller';

export default angular.module('moduleA', [])
    .controller('AppController', Controller)
    .name;

// moduleB.js 需要依赖module A
import angular from 'angular';
import moduleA from './moduleA';

angular.module('moduleB', [moduleA]);

通过这种方式，无论被依赖的模块的模块名怎么改变都不会对其他模块造成影响。

Best Practice
index.js作为框架语法包装器生成angular module外壳，同时将module.name export出去。对于整个系统而言，理想状态下只有index.js中可以出现框架语法，其他地方应该是看不到框架痕迹的。

Controller

ng1.2版本开始提供了一个controllerAs语法，自此Controller终于能变成一个纯净的ViewModel（视图模型）了，而不是像之前一样混入过多的$scope痕迹(供angular框架使用)。
example

<div ng-controller="AppCtrl as app">
    <div ng-bind="app.name"></div>
    <button ng-click="app.getName">get app name</button>
</div>

// Controller AppCtrl.js
export default class AppCtrl {
    constructor() { 
        this.name = 'angular&es6';
    }

    getName() {
        return this.name;
    }
}

// module
import AppCtrl from './AppCtrl';

export default angular.module('app', [])
    .controller('AppCtrl', AppCtrl)
    .name;

这种方式写controller等同于ES5中这样去写：

function AppCtrl() {
    this.name = 'angular&es6';
}

AppCtrl.prototype.getName = function() {
    return this.name;
};

....
.controller('AppCtrl', AppCtrl)

不过ES6的class语法糖会让整个过程更自然，再加上ES6 Module提供的模块化机制，业务逻辑会变得更清晰独立。

Best Practice
在所有地方使用controllerAs语法，保证ViewModel(Controller)的纯净。

Component(Directive)

以datepicker组件为例

// 目录结构
+ date-picker
    - _date-picker.scss
    - date-picker.tpl.html
    - DatePickerCtrl.js
    - index.js

// DatePickerCtrl.js
export default class DatePickerCtrl {

    $onInit() {
        this.date = `${this.year}-${this.month}`;
    }

    getMonth() {
        ...
    }

    getYear() {
        ...
    }
}

注意，这里我们先写的controller而不是指令的link／compile方法，原因在于一个数据驱动的组件体系下，我们应该尽量减少DOM操作，因此理想状态下，组件是不需要link或compile方法的，而且controller在语义上更贴合mvvm架构。

// index.js
import template from './date-picker.tpl.html';
import controller from './DatePickerCtrl';

const ddo = {
    restrict: 'E',
    template,
    controller,
    controllerAs: '$ctrl',
    bindToContrller: {
        year: '=',
        month: '='
    }
};

export default angular.module('components.datePicker', [])
    .directive('datePicker', ddo)
    .name;

**注意，这里跟民工叔的做法有点不一样。**叔叔的做法是把指令做成class然后在index.js中import并初始化，like this:

// Directive.js
export default class Directive {
    constructor() {
    }

    getXXX() {
    }
}

// index.js
import Directive from './Directive';

export default angular.module('xxx', [])
    .directive('directive', () => new Directive())
    .name;

但是我的意见是，整个系统设计中index.js作为angular的包装器使得代码变成框架可识别的，换句话说就是只有index.js中是可以出现框架的影子的，其他地方都应该是框架无关的使用原生代码编写的业务模型。

1.5之后提供了一个新的语法moduleInstance.component，它是moduleInstance.directive的高级封装版，提供了更语义更简洁的语法，同时也是为了顺应基于组件的应用架构的趋势(之前也能做只是语法稍啰嗦且官方没有给出best practice导向)。比如上面的例子用component语法重写的话：

// index.js
import template from './date-picker.tpl.html';
import controller from './DatePickerCtrl';

const ddo = {
    template,
    controller,
    bindings: {
        year: '=',
        month: '='
    }
};

export default angular.module('components.datePicker', [])
    .component('datePicker', ddo)
    .name;

component语义更简洁明了，比如 bindToController -> bindings的变化，而且默认controllerAs = '$ctrl'。还有一个重要的差异点就是，component语法只能定义自定义标签，不能定义增强属性，而且component定义的组件都是isolated scope。

另外angular1.5版本有一个大招就是，它给组件定义了相对完整的生命周期钩子(虽然之前我们能用其他的一些手段来模拟init到destroy的钩子，但是实现的方式框架痕迹太重，后面会详细讲到)！而且提供了单向数据流实现方式！
example

// DirectiveController.js
export class DirectiveController {

    $onInit() {
    }

    $onChanges(changesObj) {
    }

    $onDestroy() {
    }

    $postLink() {
    }
}

// index.js
import template from './date-picker.tpl.html';
import controller from './DatePickerCtrl';

const ddo = {
    template,
    controller,
    bindings: {
        year: '<',
        month: '<'
    }
};

export default angular.module('components.datePicker', [])
    .component('datePicker', ddo)
    .name;

component相关详细看这里：angular component guide

从angular的这些api变化来看，ng的开发团队正在越来越多的吸取了一些其他社区的思路，这也从侧面上印证了前端框架正在趋于同质化的事实(至少在同类型问题领域，方案趋于同质)。顺带帮vue打个广告，不论是进化速度还是方案落地速度，vue都已经赶超angular了。推荐大家都去关注下vue。

Best Practice
在场景符合(只要你的指令是可以作为自定义标签存在就算符合)的情况下都应该用component语法，在$onInit回调中做初始化处理(而不是constructor，原因见下文)，$onDestroy中作组件销毁回调。没有link方法，只有组件Controller(ViewModel).这样能帮助你从component-base的应用架构方向去思考问题。

Deprecation warning: although bindings for non-ES6 class controllers are currently bound to this before the controller constructor is called, this use is now deprecated. Please place initialization code that relies upon bindings inside a $onInit method on the controller, instead.

Service、Filter

自定义服务 provider、service、factory、constant、value

angular1.x中有五种不同类型的服务定义方式，但是如果我们以功能归类，大概可以归出两种类型：

1. 工具类／工具方法
2. 一些应用级别的常量或存储单元

angular原本设计service的目的是提供一个应用级别的共享单元，单例且私有，也就是只能在框架内部使用(通过依赖注入)。在ES5的无模块化系统下，这是一个很好的设计，但是它的问题也同样明显：

1. 随着系统代码量的增长，出现服务重名的几率会越来越大。
2. 查找一个服务的定义代码比较困难，尤其是一个多人开发的集成系统(当然你也可以把原因归咎于 编辑器/IDE 不够强大)。

很显然，ES6 Module并不会出现这些问题。举例说明，我们之前使用一个服务是这样的：

index.js

import angular from 'angular';
import Service from './Service';
import Controller from './Controller';

export default angular.module('services', [])
    .service('service', Service)
    .controller('controller', Controller)
    .name;

Service.js

export default class Service {
    getName() {
        return 'kuitos';
    }
}

Controller.js 这里使用了工具库angular-es-utils来简化ES6中使用依赖注入的方式。

import {Inject} from 'angular-es-utils/decorators';

@Inject('service')
export default class Controller {

    getUserName() {
        return this._service.getName();
    }
}

假如哪天在调用controller.getUserName()时报错了，而且错误出在service.getName方法，那么查错的方式是？我是只能全局搜了不知道你们有没有更好的办法。。。

如果我们使用依赖注入，直接基于ES6 Module来做，改造一下会变成这样：

Service.js

export default {

    getName() {
        return 'kuitos';
    }
}

Controller.js

import Service from './Service';

export default class Controller {

    getUserName() {
        return Service.getName();
    }
}