为什么有人会信 XD？这是我自 2012 年知道这个人之后一直都觉得费解的问题。一个从来都不是专注于技术的人却在技术圈子里拥有一些莫名其妙的 credits，这是值得深思的现象。

在混合范式语言里，比如 JavaScript，你说的这个就是基操。链式调用的精髓是方法自身要返回 this，至于方法是继承来的还是 mixin 混入的并没有什么区别。

@darkbaby123 提到继承和 mixin，是想说如果考虑“关注分离”（concern separation)的话 FP 和 OO 的区别，特别是 explicitly 和 implicitly 的区别。

至于你问的用继承或 mixin 来组织代码可以把 pipeline 变成 chainable，这是可行的，但不是一定的。通过继承或 mixin 得到的 methods 需要返回对象自身，满足这个前提那么就是 chainable methods。而 pipeline 不存在这个限制，这也是 @darkbaby123 说它更灵活一些的根本原因。

另外在混合范式的语言里，FP 和 OO 的特性经常是可以“互利互惠”的，比如说 JavaScript 的 pipeline operator 允许你这么来实现 mixin:

// without pipeline operator:
class Article extends Sharable(Editable(Model)) {
}

// with pipeline operator:
class Article extends Model |> Editable |> Sharable {
}

这是因为 JavaScript 的 mixin 本身就是一个 Function，它接收一个对象，返回扩展/修改后的新对象，而基于原型的 JavaScript 只需要一个对象就可以 extends（继承），于是就这样把 OO 和 FP 的特点都发挥出来了。

P.S. JavaScript 的 pipeline operator 目前还处于 proposal stage 1 的阶段，但可以使用 babel 来支持。FireFox 已经开始支持这一特性。

啧啧啧，难道这篇帖子不是后端对前端的敌意？你既全世界？你找不到靠谱的前端所以全天下的前端都是垃圾？

这图应该是搜索热度，跟性能没关系。

你定义 computed property 的时候，用 intl.primaryLocale 或者 intl.locale 作为 dependency key，这样才能在当前语言变化的时候更新。

不要用你那个 head-title 的办法，多此一举。（就算要用也应该定义成 Object-Based Helper，然后定义 compute 方法来动态更新。）

Sorry，昨天有事没有继续关注这个帖子。你后来的解法是对的。

ember-intl 有一个 IntlService，把它注入到你定义 seo meta tags 的地方，通常是路由或另外一个服务，然后调用 this.intl.t 就可以了，用法和在模板上的 {{t ...}} 一样（传参相同）。

Ru2sbty China 正式成立，预祝大会圆满成功！

也不尽然啊，如果说你只考虑做项目/产品的公司或团队协作，这么说还有情可原。可开发者并不只局限于此啊。比如说有那种独立开发者，一两个人做一个或几个商业软件出售的，人的确就不是/没有专职的产品经理，用户有什么反馈都是直接 email 或者通过别的 online support 途径来诉求，学会理解客户的需求对他们来说就是功课之一。

还有那种专职做开源软件的，可能某种意义上他们没有（或少有）商业客户，但是他们作品的使用者（大部分也是开发者）其实也是客户啊，提交 issue 或者 feature requests 本质上也是客户需求，他们往往就是自己的产品经理。

限定了工作类型的话，你的说法有道理，不过原文并没有局限“你是哪种开发者”，所以考虑到现实世界的多元性，顶多说那是可选的，仅供参考，但未必是不可行的。

不用联系我了，我只是点一下需求里不明确的地方，我个人是没有空闲时间做这些的。