修改第 4～9、11、13～14 章发现的部分错别字和语句不通顺的描述

chapters/chapter-04.md

@@ -141,6 +141,6 @@ Backbone 的神奇之处在于，在可以结合不同的框架在一起使用
 总结
 ---
 
-今天，大部分的框架并不只是那么简单。为了使用这个框架你，可能需要学习更多的框架、知识、理论。一个很好的例子就是 React，这个框架的开发人员，引入了相当多的概念，JSX、VIrtual Dom。而为了更好地使用 React 来开发，我们还需要引入其他框架，如 Redux、ES6 等等的内容。
+今天，大部分的框架并不只是那么简单。为了使用这个框架你，可能需要学习更多的框架、知识、理论。一个很好的例子就是 React，这个框架的开发人员，引入了相当多的概念，JSX、Virtual Dom。而为了更好地使用 React 来开发，我们还需要引入其他框架，如 Redux、ES6 等等的内容。
 
 这些框架从思想上存在一些差异，但是它们都有相似之处，如组件化、MV**、All in JS、模板引擎等等。欲知后事如何，请期待下一章“前端=模板 + 数据，这就是模板引擎”。

chapters/chapter-05.md

@@ -66,7 +66,7 @@
 
 我们还会发现工具栏中的 Elements 菜单自动被选上了，这是因为我们要选择的元素是属于 Elements 下的。也因此，还可以在 Elements 中选择 HTML代码，查看它在页面上的位置。它们两者是互相对应的，当我们选择一个元素时，会自动为我们选择相应的元素。
 
-编码时，可以在左侧的“元素区”编辑 HTML，右侧的区域的“Styles”可以查看元素的样式，“Computed”可以查看元素的拿模型，“Event Listeners”则可以查看元素的监听事件，等等的内容。由于 CSS 样式存在一定的优化级，如：
+编码时，可以在左侧的“元素区”编辑 HTML，右侧的区域的“Styles”可以查看元素的样式，“Computed”可以查看元素的盒模型，“Event Listeners”则可以查看元素的监听事件，等等的内容。由于 CSS 样式存在一定的优化级，如：
 
  - 元素选择器选择越精确，优化级越高
  - 相同类型选择器制定的样式，越靠后的优先级越高
@@ -119,7 +119,7 @@
 
 如果我们只是适配不同的设备屏幕，那么我们使用这个工具就够了。而当我们需要做一些设备相关的逻辑时，我们还需要使用真机来进行调试。
 
-### 真机调试：Device Inspect 
+### 真机调试：Device Inspect
 
 过去的很长一段时间里，我一直都不需要真机调试这种功能——因为只是进行响应式设计。当我们在项目上遇到一系列关于 Android 返回键的 Bug 时，我们就不得不使用设备进行调试。
 

chapters/chapter-06.md

@@ -35,7 +35,7 @@
 
 练习，那可是相当烧时间的大事；时间，又是一种相宝贵的资源。暂不说，相当于好几年的十万小时理论。对于我们这些每天要早出晚归的工作族来说，八小时以外的时间就更小了。对于一个在校的计算机专业学生来说，也不一定能在四年里搞定。
 
-而这时候如果又选择了一个错误的技术栈，哪怕是相当的浪费时间了。好在我们已经在那篇《[学习前端只需要三个月【框架篇】](https://read.douban.com/reader/column/5945187/chapter/30511309)》中讨论了如何选择一个合适的技术栈。此时还有一个问题是，如何在一个合适的时机练习它。
+而这时候如果又选择了一个错误的技术栈，那怕是相当的浪费时间了。好在我们已经在那篇《[学习前端只需要三个月【框架篇】](https://read.douban.com/reader/column/5945187/chapter/30511309)》中讨论了如何选择一个合适的技术栈。此时还有一个问题是，如何在一个合适的时机练习它。
 
 过去，习惯了将一些 Idea 放在 [GitHub](https://github.com/phodal/ideas/issues) 上变成一个清单。也因此习惯了，将一些想要玩的框架放到了 TODO Lists 中，再慢慢地享受将他们完结的愉悦感。
 
@@ -63,7 +63,7 @@
 
 我喜欢的就是这种输入和输出相结合的形式。一开始的时候，就应该先做一个应用。这种用意特别明显，借此可以快速地了解一个框架，就会觉得相当有成就感。随后就是去补缺补漏，以便于我们可以更好地完成应用。最后，当我们写文章去总结的时候，便会对这个框架有更基础的认识——像拥有一张清晰的思维导图，熟悉他的方方面面。
 
-### 使用模板 
+### 使用模板
 
 对于多数的人而言，也包括我，决定去使用一个框架的时候，表明它已经是一个几近成熟的框架——我们可以很容易找到一些资料。依据现在框架的发展趋势，大部分的框架都会提供一个脚手架，即应用程序模拟。只需要运行这个模板，我们就可以有一个 hello,world。
 
@@ -81,7 +81,7 @@
 
 我写过最多的应用就是与博客相关的应用了。当出现一个新的练手框架时，我总会用这个框架来把博客写一遍。于是，我的博客的后台 API 用 Node.js、Flask、Django 实现过一遍，而前台则用 Backbone、Angular 1、React 实现过一遍，而 APP 方面也使用 Ionic 1 和 React Native 实现过一遍。
 
-对于博客而言，我们都很轻松它的功能：列表页、详情页、登录、创建博客等等。我通常只会实现上面的四个基本元素，这和大部分应用的主要模式差不多。对于前端来说，我们会练习到基本的内容：
+对于博客而言，我们都很清楚它的功能：列表页、详情页、登录、创建博客等等。我通常只会实现上面的四个基本元素，这和大部分应用的主要模式差不多。对于前端来说，我们会练习到基本的内容：
 
  - GET 和 POST 数据
  - 列表页到详情页的跳转和返回
@@ -99,7 +99,7 @@
 
 然后，就需要了解所使用的工具对应的有什么功能。如上面说到的例子里，JSX 相当于是模板引擎、WebPack 是打包工具 / 构建工具、Babel 是 ES6 语言的编译器、Redux 用来做状态管理、React-Router 用来处理路由。
 
-最后，需要一个应用的例子来将这些内容串在一起。如当我们打开一个 Web 应用的时候，应该要有一个路由处理的工具，来将用户导向相应的页面。而这个页面会有对应的控制器和模板，路由就是来分发用户的请求。当页面数据数据或者用户操作时，页面上的数据状态就会发生变化，这时就需要状态管理工具来管理。
+最后，需要一个应用的例子来将这些内容串在一起。如当我们打开一个 Web 应用的时候，应该要有一个路由处理的工具，来将用户导向相应的页面。而这个页面会有对应的控制器和模板，路由就是来分发用户的请求。当页面数据或者用户操作时，页面上的数据状态就会发生变化，这时就需要状态管理工具来管理。
 
 幸运的是，我们已经有了一个 starter kit，在这个 starter kit 中会为我们做好相应的配置。因此，我们可以直接阅读代码来了解它们的关系，逐一的了解他们的功能。过程有点痛苦，结局便是大丰收。
 

chapters/chapter-07.md

@@ -10,13 +10,13 @@
 
 我刚开始接触前后端分离的时候，正值它开始慢慢扩散的时候，也还没有意识到它带来的好处。觉得它甚是麻烦，当我改一个接口的时候，我需要同时修改两部分的代码，以及对应的测试。反而，还不如直接修改原有的模板来得简单。
 
-可是当我去使用这个，由前后端分离做成的单页面应用时，我开始觉得这些是值得。当页面加载完后，每打开一个新的链接时，不再需要等网络返回给我结果；我也能快速的回到上一个页面，像一个 APP 一样的体现这样的应用。整个过程里，我们只是不断地从后台去获取数据，不需要重复地请求页面——因为这些页面的模板已经存在本地了，我们所缺少的只是实时的数据。
+可是当我去使用这个，由前后端分离做成的单页面应用时，我开始觉得这些是值得。当页面加载完后，每打开一个新的链接时，不再需要等网络返回给我结果；我也能快速的回到上一个页面，像一个 APP 一样的体验这样的应用。整个过程里，我们只是不断地从后台去获取数据，不需要重复地请求页面——因为这些页面的模板已经存在本地了，我们所缺少的只是实时的数据。
 
 后来，当我从架构去考虑这件事时，我才发现这种花费是值得的。
 
 ### 什么是前后端分离？
 
-前后端分离和微服务一样，渐渐地影响了新的大型系统的架构。微服务和前后端分离要解决是类似的问题，**解耦**——可以解耦复杂的业务逻辑，解耦架构。可要是说相像吧，消息队伍和前后端便相似一些，通过传递数据的形式来解耦组件。
+前后端分离和微服务一样，渐渐地影响了新的大型系统的架构。微服务和前后端分离要解决是类似的问题，**解耦**——可以解耦复杂的业务逻辑，解耦架构。可要是说相像吧，消息队列和前后端便相似一些，通过传递数据的形式来解耦组件。
 
 前后端分离意味着，**前后端之间使用 JSON 来交流，两个开发团队之间使用 API 作为契约进行交互**。从此，后台选用的技术栈不影响前台。当后台开发人员选择 Java 的时候，我可以不用 JSP 来编写前端页面，继续使用我的 React 又或者 Angular。而我使用 React 时，也不影响后台使用某一个框架。
 

chapters/chapter-08.md

@@ -16,7 +16,7 @@ SEO 优化技巧
 
 如我们在引言里所说的，搜索引擎的流量在逐渐地减弱，但是这**几乎**是一种一劳永逸的方式。只需要制定一个合理的 SEO 策略，再瞧瞧看竞争对手的规则、用户的习惯等等。我们就可以坐等：用户从搜索引擎来到我们的网站。随后的日子里，只需要跟踪用户行为的变化，再做出一些适当的改变即可。
 
-在决定玩搜索引擎优化之前，我们仍然得判断是不是需要搜索引擎优化。对于那些网站流量依赖于搜索引擎的网站来说，搜索引擎优化必要的，这样的网站有以内容为主的网站，如各种博客、知识问题类网站，网站的主要功能也是搜索的网站，如各种手机、电脑、房产网站等等。而对于大到一定体量的网站——用户已经有这个品牌意识的时候，他们对没有多大必要进行搜索引擎优化，而是更关注于如何提高用户体验。
+在决定玩搜索引擎优化之前，我们仍然得判断是不是需要搜索引擎优化。对于那些网站流量依赖于搜索引擎的网站来说，搜索引擎优化必要的，这样的网站有以内容为主的网站，如各种博客、知识问题类网站，网站的主要功能也是搜索的网站，如各种手机、电脑、房产网站等等。而对于大到一定体量的网站——用户已经有这个品牌意识的时候，他们就没有多大必要进行搜索引擎优化，而是更关注于如何提高用户体验。
 
 当我们决定为网站进行搜索引擎优先的时候，需要执行一系列相关的调查、设计，并着手开始修改代码，上线，随后再分析线上的情况，不断的改进系统。系统以一种精益的模式在运行着：
 
@@ -58,7 +58,7 @@ SEO 优化技巧
 ### 受 RESTful API 影响 的 URL 设计
 
 依据 RESTful API 原则，我们设计出来的 API 的 URL 都会有这样的缺陷。如下是 RESTful API 设计的一个简单的实例：
- 
+
  动作   | URL                    | 行为
 ---------|--------------------|----------------
 GET      | /blog               | 获取所有的文章（PS：实践的时候，通常会采用分页机制）
@@ -154,7 +154,7 @@ product/powerbank/?minPrice=100&maxPrice=150&location=shenzhen&location=shenzhen
 
 ![SEO URL](../images/seo-match-example.png)
 
-但是，不管怎样这些参数带来的影响，都是相当微弱的。正在要做好的是网站本身，以及相关的站点结构设计、网站内容。
+但是，不管怎样这些参数带来的影响，都是相当微弱的。真正要做好的是网站本身，以及相关的站点结构设计、网站内容。
 
 自动生成高质量的站点标题
 ---
@@ -175,7 +175,7 @@ product/powerbank/?minPrice=100&maxPrice=150&location=shenzhen&location=shenzhen
 
 如上图中的我的博客的标题，就是一个不错的示例。标题里带有：文章的标题，作者名、站点名、站点简介，即：``文章标题 - 作者名 | 站点名 - 站点简介``。上图中的 SegmentFault 的标题也相当的不错，``文章标题 - 专栏标题 - 站点名``。而知乎的专栏，就没有那么有趣了：``程序员如何提高影响力2.0 - 知乎专栏``。
 
-有了上面的例子之后，要完成一个相似的站点标题就更添加容易了：即将产品的相关信息带入到标题里。上面的例子中的 Title 看上去都有点生硬，如果我们愿意的话，我们也可以对其进行优化。
+有了上面的例子之后，要完成一个相似的站点标题就更加容易了：即将产品的相关信息带入到标题里。上面的例子中的 Title 看上去都有点生硬，如果我们愿意的话，我们也可以对其进行优化。
 
 该说的我们都说了，最后再来说说为什么吧。如下是 Google 搜索结果中的用户热图：
 

chapters/chapter-09.md

@@ -12,15 +12,15 @@
  - 对于工作来说，我更希望的是一个完整的解决方案。
  - 对于编程体验来说，我喜欢一点点的去创造一些轮子。
 
-当我们**会用的框架越多的时候， 所花费的时间抉择也就越多**。而单页面应用的都有一些相同的元素，对于这些基本元素的理解，可以让我们更快的适合其他框架。
+当我们**会用的框架越多的时候， 所花费的时间抉择也就越多**。而单页面应用的都有一些相同的元素，对于这些基本元素的理解，可以让我们更快的适应其他框架。
 
 单页面应用的演进
 ---
 
 我接触到单页面应用的时候，它看起来就像是**将所有的内容放在一个页面上么**。只需要在一个 HTML 写好所需要的各个模板，并在不同的页面上 data-role 表明这是个页面（基于 jQuery Mobile）——每个定义的页面都和今天的移动应用的模式相似，有 header、content、footer 三件套。再用 id 来定义好相应的路由。
 
 ```
-<div data-role="page" id="foo"> 
+<div data-role="page" id="foo">
 ...
 </div>
 ```
@@ -38,11 +38,11 @@
 当移动设备的性能越来越好时，开发者们开始在浏览器里渲染页面：
 
  - 使用 jQuery 来做页面交互
- - 使用 jQuery Ajax 来从服务端获取数据 
+ - 使用 jQuery Ajax 来从服务端获取数据
  - 使用 Backbone 来负责路由及 Model
  - 使用 Mustache 作为模板引擎来渲染页面
  - 使用 Require.js 来管理不同的模板
- - 使用 LocalStorage 来存储用户的数据 
+ - 使用 LocalStorage 来存储用户的数据
 
 通过结合这一系列的工具，我们终于可以实现一个复杂的单页面应用。而这些，也就是今天我们看到的单页面应用的基本元素。我们可以在 Angular  应用、React 应用、Vue.js 应用 看到这些基本要素的影子，如：Vue Router、React Router、Angular 2 RouterModule 都是负责路由（页面跳转及模块关系）的。在 Vue 和 React 里，它们都是由辅助模块来实现的。因为 React 只是层 UI 层，而 Vue.js 也是用于构建用户界面的框架。
 
@@ -53,11 +53,11 @@
 
 1. 浏览器会检查有没有相应的域名缓存，没有的话就会一层层的去向 DNS服务器 寻向，最后返回对应的服务器的 IP 地址。
 2. 接着，我们请求的网站将会将由对应 IP 的 HTTP 服务器处理，HTTP 服务器会根据请求来交给对应的应用容器来处理。
-3. 随后，我们的应用将根据用户请求的路径，将请求交给相应的函数来处理。最后，返回相应的 HTML 和资源文化
+3. 随后，我们的应用将根据用户请求的路径，将请求交给相应的函数来处理。最后，返回相应的 HTML 和资源文件。
 
 当我们做后台应用的时候，我们只需要关心上述过程中的最后一步。即，将对应的路由交给对应的函数来处理。这一点，在不同的后台框架的表现形式都是相似的。
 
-如 Python 语言里的 Web 开发框架 Django 的 URLConf，使用正规表达式来表正
+如 Python 语言里的 Web 开发框架 Django 的 URLConf，使用正则表达式来表示
 
 ```
 url(r'^articles/2003/$', views.special_case_2003),
@@ -73,7 +73,7 @@ Route::get('posts/{post}/comments/{comment}', function ($postId, $commentId) {
 
 虽然表现形式有一些差别，但是总体来说也是差不多的。而对于前端应用来说，也是如此，**将对应的 URL 的逻辑交由对应的函数来处理**。
 
-React Router 使用了类似形式来处理路由，代码如下所示：	
+React Router 使用了类似形式来处理路由，代码如下所示：
 ```
  <Route path="blog" component={BlogList} />
  <Route path="blog/:id" component={BlogDetail} />
@@ -171,7 +171,3 @@ fetch(url).then(response => response.json())
 事实上，对于用户交互来说也只是改变状态的值，即对状态进行操作。
 
 举一个例子，当用户点击登录的时候，发送数据到后台，由后台返回这个值。由控制器一一的去修改这些状态，最后确认这个用户登录，并发一个用户已经登录的广播，又或者修改全局的用户值。
-
-
-
-