英文原文：JavaScript Application Architecture On The Road To 2015

我曾经跟人说我是一名架构师，也确实如此，我现在不克不及不编造一大串谎话来使人信服。说到正题，我认为在即将跨入 2015 年之际聊聊 Javascript 社区的运用次序架构的展开形状也是挺不错的。接下来，我将要讲讲组合、功用鸿沟、模块化、不成变数据结构、CSP（通信次第进程）通道和一些相关的话题。

组合

在架构层面，我们应用JavaScript处理大范畴运用的办法在过去的几年里爆发了根本性变卦。移除机械细节，引入了改进的数据绑定，不成变数据结构和虚拟DOM（一切这些都是幽默的问题），非常多开发者将其有机地融合为一个关键观念——组合。组合令人难以置信的弱小，可让我们来结合可重用的功用块来”组分化“一个更大的运用。组合组成了一种新外形，越是模块化、小巧且随便测试的Tools越好。易于选择。易于建设。只需看看它们在Node中怎样Task的就清楚了。

组合的一个例子就像运用是由小块的可重用UI组成，而它们本身就是可扩展和重用现有模块和库的组件。

组合（组件）是我们谈判react，ember ,angular ，polymer这些框架，和我们自己写的web 组件的话题之一。也许我们会对不合框架也许库的风格（办法）辩论不休，可是这实在不料味着组件是个坏任务。需求留心的时，真实的了解组合（组件）的威力并不是一件随便的事；固然随着Dojo YUI ExtJS等框架大力建议，这个观念已经广为人知。

组件化是应对app复杂性的处置办法之一。由于复杂性而带来的痛苦间接抚慰着web平台言语的不时退步。复杂性本身来自于不合的运用场景，表现为不合的方法，因此复杂性的处置办法也是各色各样的。可是着眼于最近几年来开发人员构建app的办法，这些common patterns 是值得思考的Tools。web组件的首要性也因此失掉了浏览器供应商的供认。不管你如何看，归正我是力挺组件的，也许你能在组合这类处置办法上有足够的开掘，来掌握他。

我渴望未来能有所改进的地方在于，Dom和数据（model/server）之间的形状同步（一致），和composition boundaries(组合鸿沟)的使用。

组合鸿沟

谈到组合，我们得先聊聊阴影DOM鸿沟。但凡我们会应用浅显HTML构造部件，这些部件之间具有真实的功用鸿沟，这是我们特殊值得关注的特点。这类特点让我们明白当一个部件树终了时，别的一个部件树会从那边Start，从而使我们可以避免由于全体页面的某一控件越界招致的问题。它也便于我们减少CSS选择器的适配范围，这类深层次的部件结构可以樊篱掉样式规则的复杂性。

阴影鸿沟作为分界线，将浅显DOM（轻型DOM）从阴影DOM等分离开来。

其它翻译版本 (1) 加载中

假设你还没有效过 Shadow DOM，（让我来引见下它的功用）它容许浏览器在衬着文档时拔出一棵DOM子树（也许类似的组件），可是不能拔出到页面的主DOM树中。多么就在一个组件和下一个组件间组成了一个组合鸿沟，它为构建小的、自力的组件而不用依托框架供应了支撑。支持Shadow DOM的浏览器可以自由地跨越鸿沟，在DOM元素子树的内部，你可以使用已存在的div、input、select标签再次构建一个相似的元素。从组件完成细节思考，这也保护了隐藏在Shadow DOM内部的页面其他部分。

Iframe 在从完成结构与样式分别Start就在应用，Shadow DOM 与只应用 iframe 比拟怎样？实在不会让人感到恐惧，之前iframe是把完好分别的HTML文档拔出到此外一个文档傍边，意思就是故意为之，意思就是访问一个现存的iframe（一个完好自力的内容）中的DOM元素默许情况下是不成行的。并且也思考用这类机制向页面 ’拔出‘多组件。在iframe承载的内容中，每种情况下，你都可以点击访问一个自力的URL，把笨重的无语法意义的iframe标签标记丢到一边。在组成鸿沟应用了Shadow DOM的组件，该当（也许必须）可以像外地HTML元素一样间接删除或修改。

有点人可能觉得组合（composition）（太复杂了，）就像是魔鬼的代言人,不应该出现在表现层(它可不是像茶杯一样让你可以随意应用),其他人也许会赞成。但毫无疑问，完好可以使用组件的组合来替换影子DOM（Shadow DOM）,可是为了应用组件组合,（价钱也很高，）你超级不克不及不非常严峻地限制组件的鸿沟，当然也可以颠末添加额外笼统的办法来应用，而影子DOM就是多么一种供应平台级笼统的完成办法。

现在，影子DOM（Shadow DOM）在Chrome浏览器已经是原生就有的，未来也会在其他浏览器出现，令人激动的是,我们已经看到有一些项目正在探求完成对Shadow DOM的支持，例如：React正在探求增加对影子DOM（Shadow DOM）的支持，渴望能尽快看到结果；Polymer已经支持影子DOM（Shadow DOM）；Ember和 Angular项目似乎也有兴味探求这一范围。

组件消息

组件(component)之间如何传递消息? 假设你方案处置组件间的退耦, 模块化问题, 倒是有几个方法可以用.

由组件的 API 间接引用, 这类方法不成取 (除非是比拟轻易的Tools), 因为这会招致代码依托其他组件的某些版本. 比如这些组件的 API 爆发较大的变更, 你要么花钱升级, 要么认栽. 真实, 我们可以使用经典的全局(global)/组件间(in-component)工作系统. 假如你需求在没有父子(parent-child)关系的组件间传递消息, 那么, 工作 + 订阅(subscription) 依然是不错的选择. 现实上, React 也举荐这类办法. 当然, 假设组件之间存在父子关系, 间接传递 props 就可以够了. Angular 用 Services 担负组件间的消息传递. Polymer 则用以下几种方法: 自定义工作, 变卦观察器(change watcher) 和  `<core-signals>` 元素.

我们已经做到最好了么？当然没有。关于你将要触发的工作(fire-and-forget)，全局工作系统模型相当不错，但一旦你需求存在形状的工作(stateful event)也许链(chaining)，这会变得很胆怯。 随着复杂性的提高，你会创造工作与通信及Task流操纵交织在一同。在你可以使用多种方法来提升工作系统(比如函数响应式编程)的同时你也会创造你的工作运转着庞大数量的代码。

比全局工作系统好些的是CSP (Communicating Sequential Processes，通信次第进程), 一种描画并发系统中通信的正式方法。CSP通道在ClojureScript或Go中可以找失掉并且在core.async项目中已经被正式化。CSP管理进程的调和性，颠末传递消息，当从通道中提取或放置时阻塞运转，更轻易的表现复杂的异步流。它处置了你可能在某种程度上需求应用双通道和依托于强类型(stringly-typed)常规方法的问题：

thingNeedsPhoto { id: 001, uuid: “foo” }
thingPhoto { data: “../photo.png”, uuid: “foo” }

本文中的一切译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译Task依照 CC 协议，假设我们的Task有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务