diff --git a/chapters/chapter-04.md b/chapters/chapter-04.md index 099b266..1083ccc 100644 --- a/chapters/chapter-04.md +++ b/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、模板引擎等等。欲知后事如何，请期待下一章“前端=模板 + 数据，这就是模板引擎”。 diff --git a/chapters/chapter-05.md b/chapters/chapter-05.md index 521c055..cceeb15 100644 --- a/chapters/chapter-05.md +++ b/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 时，我们就不得不使用设备进行调试。 diff --git a/chapters/chapter-06.md b/chapters/chapter-06.md index 7df9f7f..8c22c2b 100644 --- a/chapters/chapter-06.md +++ b/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 中会为我们做好相应的配置。因此，我们可以直接阅读代码来了解它们的关系，逐一的了解他们的功能。过程有点痛苦，结局便是大丰收。 diff --git a/chapters/chapter-07.md b/chapters/chapter-07.md index 8557eab..c95c5cb 100644 --- a/chapters/chapter-07.md +++ b/chapters/chapter-07.md @@ -10,13 +10,13 @@ 我刚开始接触前后端分离的时候，正值它开始慢慢扩散的时候，也还没有意识到它带来的好处。觉得它甚是麻烦，当我改一个接口的时候，我需要同时修改两部分的代码，以及对应的测试。反而，还不如直接修改原有的模板来得简单。 -可是当我去使用这个，由前后端分离做成的单页面应用时，我开始觉得这些是值得。当页面加载完后，每打开一个新的链接时，不再需要等网络返回给我结果；我也能快速的回到上一个页面，像一个 APP 一样的体现这样的应用。整个过程里，我们只是不断地从后台去获取数据，不需要重复地请求页面——因为这些页面的模板已经存在本地了，我们所缺少的只是实时的数据。 +可是当我去使用这个，由前后端分离做成的单页面应用时，我开始觉得这些是值得。当页面加载完后，每打开一个新的链接时，不再需要等网络返回给我结果；我也能快速的回到上一个页面，像一个 APP 一样的体验这样的应用。整个过程里，我们只是不断地从后台去获取数据，不需要重复地请求页面——因为这些页面的模板已经存在本地了，我们所缺少的只是实时的数据。 后来，当我从架构去考虑这件事时，我才发现这种花费是值得的。 ### 什么是前后端分离？ -前后端分离和微服务一样，渐渐地影响了新的大型系统的架构。微服务和前后端分离要解决是类似的问题，**解耦**——可以解耦复杂的业务逻辑，解耦架构。可要是说相像吧，消息队伍和前后端便相似一些，通过传递数据的形式来解耦组件。 +前后端分离和微服务一样，渐渐地影响了新的大型系统的架构。微服务和前后端分离要解决是类似的问题，**解耦**——可以解耦复杂的业务逻辑，解耦架构。可要是说相像吧，消息队列和前后端便相似一些，通过传递数据的形式来解耦组件。 前后端分离意味着，**前后端之间使用 JSON 来交流，两个开发团队之间使用 API 作为契约进行交互**。从此，后台选用的技术栈不影响前台。当后台开发人员选择 Java 的时候，我可以不用 JSP 来编写前端页面，继续使用我的 React 又或者 Angular。而我使用 React 时，也不影响后台使用某一个框架。 diff --git a/chapters/chapter-08.md b/chapters/chapter-08.md index d51cac3..5e1ca4d 100644 --- a/chapters/chapter-08.md +++ b/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 搜索结果中的用户热图： diff --git a/chapters/chapter-09.md b/chapters/chapter-09.md index 56bf31b..26e24ef 100644 --- a/chapters/chapter-09.md +++ b/chapters/chapter-09.md @@ -12,7 +12,7 @@ - 对于工作来说，我更希望的是一个完整的解决方案。 - 对于编程体验来说，我喜欢一点点的去创造一些轮子。 -当我们**会用的框架越多的时候， 所花费的时间抉择也就越多**。而单页面应用的都有一些相同的元素，对于这些基本元素的理解，可以让我们更快的适合其他框架。 +当我们**会用的框架越多的时候， 所花费的时间抉择也就越多**。而单页面应用的都有一些相同的元素，对于这些基本元素的理解，可以让我们更快的适应其他框架。 单页面应用的演进 --- @@ -20,7 +20,7 @@ 我接触到单页面应用的时候，它看起来就像是**将所有的内容放在一个页面上么**。只需要在一个 HTML 写好所需要的各个模板，并在不同的页面上 data-role 表明这是个页面（基于 jQuery Mobile）——每个定义的页面都和今天的移动应用的模式相似，有 header、content、footer 三件套。再用 id 来定义好相应的路由。 ``` -
+
...
``` @@ -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 使用了类似形式来处理路由，代码如下所示： ``` @@ -171,7 +171,3 @@ fetch(url).then(response => response.json()) 事实上，对于用户交互来说也只是改变状态的值，即对状态进行操作。 举一个例子，当用户点击登录的时候，发送数据到后台，由后台返回这个值。由控制器一一的去修改这些状态，最后确认这个用户登录，并发一个用户已经登录的广播，又或者修改全局的用户值。 - - - - diff --git a/chapters/chapter-11.md b/chapters/chapter-11.md index 60ad193..1451e83 100644 --- a/chapters/chapter-11.md +++ b/chapters/chapter-11.md @@ -32,7 +32,7 @@ 我们可以看到这里的主要限制因素是，TTFB。而要对 TTFB 优化的话，就需要关心两部分： - 服务器。比如：如果有复杂的防火墙规则或路由问题，则TTFB时间可能很大。又或者是你的服务器性能不好，但是你启用了 GZIP 压缩，那么它也将增加 TTFB 所需要的时间。 - - 应用程序。比较简单的作法是和我一样，交这部分交给 New Relic 去处理，我们就可以知道应用中哪些地方比较占用资源。 + - 应用程序。比较简单的作法是和我一样，将这部分交给 New Relic 去处理，我们就可以知道应用中哪些地方比较占用资源。 ### TTFB 优化 @@ -54,7 +54,7 @@ ![NewRelic Result](../images/newrelic.png) -如当用户访问博客的列表页时，大概需要 500+ ms 左右的时间，而一篇详情页则差不多是 200ms+。对于数据查询来说，除了使用更多、更好的服务器，还可读减少对数据的查询——即缓存数据结果。 +如当用户访问博客的列表页时，大概需要 500+ ms 左右的时间，而一篇详情页则差不多是 200ms+。对于数据查询来说，除了使用更多、更好的服务器，还可以减少对数据的查询——即缓存数据结果。 而在当时，我并没有注意博客对于缓存的控制，主要是因为使用的静态资源比较少。这一点直到我实习的时候才发现。 @@ -70,7 +70,7 @@ - 缓存 HTML 结果。缓存请求过的内容，可以减少应用计算的时间。 - 等等 -对于 CSS 和 JS 压缩这部分来说，我们可以从工程上来实现，也可以使用诸如 Nginx Pagespeed 这样的工作来实现。但是我想使用工程手段更容易进行控制，并且不依赖于 HTTP 服务器。 +对于 CSS 和 JS 压缩这部分来说，我们可以从工程上来实现，也可以使用诸如 Nginx Pagespeed 这样的工具来实现。但是我想使用工程手段更容易进行控制，并且不依赖于 HTTP 服务器。 设置资源的缓存时间就比较简单了，弄清楚 Last-Modified / Etag / Expires / Cache-Control 几种缓存机制，再依据自己的上线策略做一些调整即可。 @@ -92,7 +92,7 @@ 因此，在完成移动应用的时候，我们都会缓存 API 的结果。并在页面的生命周期内，对页面进行优化。 -### 缓存 API 结果 +### 缓存 API 结果 ### 生命周期优化 @@ -102,4 +102,3 @@ 在对应用进行优化的过程中，还会遇到一个非常有意思的问题：你将采用的优化方案，往往是和业界所推荐的最佳模式相违背的。如 inline css 对于用户来说，可以获得更好的体验效果。又如更快的 Google AMP，则能在打开速度上有更大的提升，但是却和最佳实践相去甚远。 待续~~ - diff --git a/chapters/chapter-13.md b/chapters/chapter-13.md index 3fafdcc..0fed5d5 100644 --- a/chapters/chapter-13.md +++ b/chapters/chapter-13.md @@ -94,7 +94,7 @@ API 设计应该由前端开发者来驱动的。后台只提供前端想要的 - 维护 API 文档很痛苦 - 需要一个同步的 Mock Server -而在早期，开发人员有同样的问题，于是他们有了 JavaDoc、JSDoc 这样的工具。它可以一个根据代码文件中中注释信息，生成应用程序或库、模块的API文档的工具。 +而在早期，开发人员有同样的问题，于是他们有了 JavaDoc、JSDoc 这样的工具。它可以根据代码文件中注释信息，生成应用程序或库、模块的API文档的工具。 ![JSDoc](../images/jsdoc.png) @@ -137,7 +137,7 @@ paths: {} 其步骤如下： - 编写契约（即 API）。即规定好 API 请求的 URL、请求内容、返回结果、鉴权方式等等。 - - 根据契约编写 Mock Server。可以彩 Moco + - 根据契约编写 Mock Server。可以采用 Moco - 编写集成测试将请求发给这个 Mock Server，并验证 如下是我们项目使用的 [Moco](https://github.com/dreamhead/moco) 生成的契约，再通过 [Moscow](https://github.com/macdao/moscow) 来进行 API 测试。 @@ -166,7 +166,7 @@ paths: {} ![前端-后台与契约](../images/contract-fe.png) -当契约发生发动的时候，持续集成便失败了。因此相应的后台测试数据也需要做相应的修改，相应的前端集成测试也需要做相应的修改。因此，这一改动就可以即时地通知各方了。 +当契约发生变动的时候，持续集成便失败了。因此相应的后台测试数据也需要做相应的修改，相应的前端集成测试也需要做相应的修改。因此，这一改动就可以即时地通知各方了。 ### 前端测试与 API 适配器 diff --git a/chapters/chapter-14.md b/chapters/chapter-14.md index 255c812..bbfa809 100644 --- a/chapters/chapter-14.md +++ b/chapters/chapter-14.md @@ -24,7 +24,7 @@ - 怎样去部署当前的应用 - 发布策略：红绿发布，以及 Toggle -倘若，平时能像工作上走这些流程，那定能是提升自身的水平。工作上，需要更多的业务探索。而日常，则需要更多的技术发掘。 +倘若，平时能像工作上走这些流程，那定能提升自身的水平。工作上，需要更多的业务探索。而日常，则需要更多的技术发掘。 前端应用的生命周期 ---