强迫症的模块化

发表于

在ES2015发布后,JavaScript最终也有了一个标准的模块化方案,而同时从webpack开始,也带来了一波“一切皆模块”的潮流。整个2015-2016的前端发展中,除去在UI层不断的努力和突破外,几乎每一件事都和模块化脱不开关系。 本文也试图从几个方面简单地说一下模块化,并分析一些在模块化实施中产生的误区。 模块的本质 模块化顾名思义,指的必然是将程序拆分为多个“模块”,使用模块间通信的方式进行交互。这和其它对程序逻辑进行拆分的手段是一样的,无论是拆成类、拆成对象还是拆成啥,其目的无非是隔离内部的实现以及声明对外的接口。 事实上自远古时代起,JavaScript就在努力进行实现封装的尝试,无论是通过IIFE避免全局变量,还是基于Namespace进行管理,以至后期的AMD、CJS社区模块化方案,

使用高阶函数实现类的扩展设计

发表于

在不少框架中,都会对“扩展”这一概念有需求。所谓扩展,即一个可组合的组件,用于嵌入到目标的生命周期中,对目标的行为进行额外的处理使得目标拥有不同的表现。 一个非常简单的案例即日志的记录。通常框架自身并不会有业务相关的日志记录的功能,而业务代码也不希望混入并非业务逻辑的日志记录部分。那么使用一个扩展,在合适的点进行日志的收集和存储是很合适的设计。 在以往,比较流行的扩展通常有几种形式: Mixin形式。这种形式下扩展与目标形成完全的覆盖关系,属于暴力而简单的方法。 class Component { constructor({mixins}) { mixins.forEach(mixin =>

ES Decorators简介

发表于

我跟你说,我最讨厌“简介”这种文章了,要不是语文是体育老师教的,早就换标题了! Decorators是ECMAScript现在处于Stage 1的一个提案。当然ECMAScript会有很多新的特性,特地介绍这一个是因为它能够在实际的编程中提供很大的帮助,甚至于改变不少功能的设计。 先说说怎么回事 如果光从概念上来介绍的话,官方是这么说的: Decorators make it possible to annotate and modify classes and properties at

PC端大型单页式商业内容管理系统的JS模块化构建探索

发表于

前提 为了不被喷得太惨,给标题加了这么多的限制定语也是相当不容易的了。此文讨论的是我所处的环境下对JavaScript构建的一些简单探索,因此有相当多的前提限制。 首先,何为大型。从我们的系统来看,20多个业务模块,近100个页面组成的单页系统,对应的业务源码代码量如下: 对应的依赖库,除underscore和moment外均为公司内部库,代码量为: 其次,所谓的“模块化”指我们使用AMD进行构建,使用符合社区AMD标准的Loader进行模块的加载。 而“PC端单页式商业内容管理系统”则代表着系统的不少特性: 使用是相对强制的,对用户来说这是一项工作,而不是爱用不用的用户产品。 商业公司通常拥有较好的网络环境,

博客单页化实践

发表于

这个单页化的博客现在也没在用了,Ghost平台挺好的……如果需要看代码的话,请参考GitHub上的仓库 半年前,因为VPS未续费导致所有数据丢失,直至今日终于重新恢复了所有的文章数据(虽然丢失了全部的评论),并且借此机会对所有文章进行了一次重新审视,修改了部分问题,并将所有示例迁移到jsfiddle和jsperf上,总算造一段落。 新的博客完全独立建设,不使用任何第三方的CMS系统,后端使用ASP.NET MVC实现,数据库使用MySQL,通过Mono部署于Ubuntu Server之上,前端使用nginx作为静态服务器。 也正因为完全独立构建,不受任何系统出于安全、简便等奇怪理由而附加的限制,这个博客系统也成了自己练手的娱乐场。就比如本篇要介绍的OPOA化实践。