Render Props最近在React社区中引起了轰动，但是与之类似的模式在Angular中似乎并没有得到太多关注。我在之前写的文章提及过，TemplateRefs就是Angular中的Render Props，同时我会在这篇文章中列举一个简单易用的例子。

你可能知道，当我们通过@NgModule()装饰器来声明一个service时，它将符合单例模式，同时还意味着它与整个应用的生命周期保持一致。比如： {代码...} 我们在刚开始接触Angular的时候，总是不计后果的将所有service都使用@NgModule()来声明，这将会造成一个不易发现的问题： You are not releasing memory. 在上面的例子中...

在上一篇文章RPC vs REST vs GraphQL中，对于这三者的优缺点进行了比较宏观的对比，而且我们也会发现，一般比较简单的项目其实并不需要GraphQL，但是我们仍然需要对新的技术有一定的了解和掌握，在新技术普及时才不会措手不及。

最近2周的时间由于工作不忙，一直在看有关GraphQL的东西，前后端均有涉及，由于我之前做过后端开发，当时实现的接口的大体是符合RPC风格的接口。后来转做了前端开发，从实现接口者变成了调用接口者，接触最多的当属REST风格的接口。因此在这段学习GraphQL的过程中，并且也尝试使用它以全栈的角度做了一个小项目，在这个...

在之前的例子中，已经出现多次使用template reference variable（模板引用变量）的场景，现在让我们来深入研究如何通过使用模板引用变量来关联某个具体指令的引用。

命名冲突不仅存在于指令的选择器之间，同时也会存在于指令的Inputs和Outputs属性，当这些属性名一样时，Angular并不会进行提示，它会按原本的逻辑正常工作。这种情况有时候是我们希望看到的，有些时候却不是。

Objects should be replaceable with instances of their subtypes without altering the correctness of that program.某个对象实例的子类实例应当可以在不影响程序正确性的基础上替换它们。

Clients should not be forced to depend on methods that they do not use.客户端代码不应当被迫依赖于它们不需要的方法。

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.软件实体（类、模块、函数等）都应当对扩展具有开放性，但是对于修改具有封闭性。

之前的第一篇文章阐述了依赖倒置原则（DIP）能够使我们编写的代码变得低耦合，同时具有很好的可测试性，接下来我们来简单了解下单一职责原则的基本概念：

当我们在读书，或者在和一些别的开发者聊天的时候，可能会谈及或者听到术语SOILD。在这些讨论中，一些人会提及它的重要性，以及一个理想中的系统，应当包含它所包含的5条原则的特性。

最近正好在看web worker相关的东西，今天无意中就看到了github一周最热项目的推送中，有这么一个项目workerize，repo里的文档的描述如下：

Kent C. Dodds的第四篇文章中的一个重要元素在上一篇文章中没有涉及，使用withToggle高阶组件(HoC, react中的常用模式)可以将<toggle-on>、<toggle-off>、<toggle-button>组件中的公用逻辑分离出来。

我们无法在其中方式多个<toggle-on>或者是<toggle-button>在同一个<toggle>中

我们可以把toggle抽象为一个复合组件，由三个新的组件<toggle-button>、<toggle-on>、<toggle-off>构成。

Angular到现在已经到5.x的版本了，对于MVVM框架我首先接触的是angularjs后来又转为react，之后换了工作因项目技术栈的原因又转换到之前的angularjs，在实际工作中实施了公司几个比较重要项目中前端的重构工作，这个过程逐步意识到，对于MVVM框架本身，在使用层面讲，掌握一些通用的模式是很有必要的，尤其现在已经很流行...

给予一个多维数组和一个描述取值路径的一维数组, 通过调用函数f返回取值路径描述的值，如f([[1, 2], [3, 4], [5, 6]], [0, 0]) -> 1

最近一直在折腾redux相关的东西，算然说官方鼓励的使用方式是将redux和react一起使用，但并不影响我们在其他的mvvm框架中使用它。