前端架构（一）

接下来我会在不一样阶段去分析前端架构的一些细则和先后端交互的要点，逐一剖析

前端架构概念

web应用复杂度的增长，特别是单页面应用的风靡。组件化，工程化，自动化成了前端发展的趋势。或者说一线的互联网公司就是这么作的。一般说架构，指的是架构模式，自创的架构不多。了解架构模式，才能心有余力的应对项目的发展。

前端工程的阶段

第一阶段： 库/框架选型（解决开发效率）

Animate.css
jQuery
vue.js
underscore.js
React.js
Backbone.js
Bootstarp
zepto.js
jade
normalize.css
compass
Angular.js

第二阶段： 简单构建优化 总体渲染

选择构建工具，对代码进行压缩，校验，以后再以页面为单位进行简单的资源合并。 全部页面代码放到了一个html文档中，适合我的实验室项目。 新建一个文件，快速的验证某个功能或者开发某个组件，再移植到开发环境中。
优势：开发速度快，执行过程清晰
不足：不容易分工合做

第三阶段： 结构行为表现分离，JS/CSS模块化开发

结构：HTML
行为：JavaScript
表现：CSS
解决维护效率 js的模块化方案 ADM/CDM/UMD/ES6 Module
css的模块化：less，sass。

第四阶段： 插件

对需求的响应快，更快的实现页面的UI样式，前端更快捷的实现页面布局，使前端把重点放在业务逻辑上

第五阶段：模块

主要如下几种模块规范
（1）AMD规范（用户客户端，RequireJS实现）
（2）CommonJS规范（用于服务端，Browserify实现）
（3）EcmaScript 6 Module

js

如今ES6已经在语言层面上规定了模块系统，彻底能够取代现有的CommonJS和AMD规范，并且使用起来至关简洁，而且有静态加载的特性。

1.用++Webpack + Babel++将全部模块打包成一个文件同步加载，也能够搭乘多个chunk异步加载；
2.用++System+Babel++主要是分模块异步加载；
3.用浏览器的< script type="module">加载。

css

虽然SASS、LESS、Stylus等预处理器实现了CSS的文件拆分，但没有解决CSS模块化的一个重要问题：选择器的全局污染问题。

按道理，一个模块化的文件应该要隐藏内部做用域，只暴露少许接口给使用者。而按照目前预处理器的方式，导入一个CSS模块后，已存在的样式有被覆盖的风险。虽然重写样式是CSS的一个优点，但这并不利于多人协做

资源的模块化

Webpack的强大之处不只仅在于它统一了JS的各类模块系统，取代了Browserify、RequireJS、SeaJS的工做。更重要的是它的万能模块加载理念，即全部的资源均可以且也应该模块化。

资源模块化后，优势是：

依赖关系单一化。全部CSS和图片等资源的依赖关系统一走JS路线，无需额外处理CSS预处理器的依赖关系，也不需处理代码迁移时的图片合并、字体图片等路径问题； 资源处理集成化。如今能够用loader对各类资源作各类事情，好比复杂的vue-loader等等； 项目结构清晰化。使用Webpack后，你的项目结构总能够表示成这样的函数： dest = webpack(src, config)。

第六阶段：前端工程化

前端工程化项目分为3大模块

1. Node服务，提供数据代理，路由，和服务器渲染，经过restful api和后端通讯。
2. web应用开发，专一于web交互体验。
3. 前端运维：包含构建，测试，部署及监控等。

静态资源与Node端衔接：

• 前端静态资源构建工做与Node服务相互分离，Node服务在开启的过程当中会读取前端构建生成的静态资源映射表。
• 静态资源映射表的生成：
• 预编译：ES6语法转义，css预编译器处理，源码质量审查，测试
• 模块依赖解析
• 压缩，静态资源版本号

第七阶段：组件化

组件组件并非一个新兴的概念， 可是React.js强制组件化，因此看来才那么新颖。它把JavaScript，CSS，HTML从新打包。 从UI拆分下来的每一个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元，咱们称之为组件。
单一职责原则：一个类应该只有一个发生变化的缘由。
组合/汇集复用原则：尽可能使用合成/聚合，而不是使用继承。

鼓励遵循下面几条“约定”：

• Ajax请求从Node端代理，而非具体后端服务。
• 鼓励将JavaScript、CSS、HTML视为前端领域的“汇编”。
• 重视前端页面状态管理，推荐的方案有Redux、vuex及MobX等。
• 强调组件化，面向组件集开发。
• 项目的脚手架，来搭建项目的开发环境。