共计 36944 个字符，预计需要花费 93 分钟才能阅读完成。
博客归档地址：https://github.com/pkwenda/blog
博客实例地址：https://github.com/pkwenda/new-bee
这个系列我全副采纳了目前比拟支流技术栈
整体纲要的把握
这个系列文章我尽量关照前端的同学和后端的同学，不交叉讲述。尽量依照前端 - 后端 - 部署 - 运维来讲，当然中途波及到 跨域 、Rest、oAuth2.0 这种前后协调的还是无奈防止捎带一笔。
比方:
这种目录浏览可能对于只把握 前端 / 后端 一种技术栈的同学，或只想去看 后端 / 前端 / 运维 的同学看上去十分的好受、我会批改纲要防止这个问题, 循序渐进的来。
你会学到
- 深刻理解前后拆散，理解常见架构
- 前端后端我的项目的搭建与优化
- 前端后端技术的选型
- 开发过程中晋升效率的小技巧
- 不同场景下跨域的 N 种解决办法
- 几个良好习惯晋升 debug 的能力
- 前端的 Hybrid 开发本人的 APP
- 前端 SPA 模式的优化
- 学会爬取咱们想要的 资源
- 后端架构如何向微服务转型
- 如何应用 docker 部署微服务
- 如何保护我的项目的运行
如何从零打造一个前后拆散的互联网支流 WEB 我的项目、真心心愿我能帮到你们。
Part 2 : 纵观 WEB 历史演变
在校学习和几年工作工作中人不知; 鬼不觉经验了一半的 WEB 历史演变、对近几年的倒退比拟理解，联合教训聊聊 WEB 倒退历史。
演变不易，但也是必然，因为为人始终要提高。
WEB 的发展史
一、开山鼻祖 – 石器时代
动态网站
这是 1997 年 Apple 官网，那时的网站不如叫网页，像一张虚夸的黑白报纸，那时是纯正的 HTML 时代，不论你是不是拜访这个网页，每个页面都是在服务器上存在的。
CGI 技术
随后技术性强一点的网站可能会通过 CGI Perl 运行一小段代码与数据库或文件系统进行交互。比方：
这是 1998 年的 Google，为了达到搜寻条件，不可能用大量的人力去堆砌 动态页面, 所以应用这种形式“曲线救国”，然而 CGI 伸缩性不是太好：每个申请调配一个新的过程，不太平安(间接应用文件系统或者环境变量)，同时也没提供一种结构化的形式去结构动静应用程序。
动态网站是最受搜索引擎欢送的网站，因为它绝对固定，所以网站 SEO 十分好做，我猜想这也是为什么当初的文档网站大部分都是动态网页的起因之一吧。
很惋惜我没能亲眼看一看这样的时代
二、前人种树 – 文化时代
asp 和 jsp
2005 年左右，先后呈现了 微软的 ASP 和 Java Server Pages [JSP] 等技术, 取代了 CGI，加强了 WEB 与服务端的交互的安全性、用起来也更加简略，但随着各个公司 WEB 业务的复杂性，毛病也逐步裸露进去：
1、技术繁多，难以保护
JSP 页面由 HTML 代码和嵌入其中的 Java 代码所组成, 用一个比拟常见的 JSP 代码段举例：
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>
<%@ page import="com.zifangsky.OnlineFriend.model.article.ShowByPage"%>
<jsp:useBean id="showAllTitle" type="com.zifangsky.OnlineFriend.model.article.ShowByPage" scope="session"/>JSP = HTML+Java
下面的代码 HTML 中大量耦合了 JAVA 代码，通过 JSP 编译之后能够在客户端充当局部服务端的角色，这让咱们难以搞清服务端的角色，以及减少调试的复杂度。业务略微简单一点，试想一下：HTML 中掺杂了太多 java 代码，不论是开发还是保护都是一件苦楚的事件。
2、不不够灵便
JSP 与 Java Servlet 一样，是在服务器端执行的，通常返回该客户端的就是一个 HTML 文本。咱们每次的申请：获取的数据、内容的加载，都是服务器为咱们返回染实现之后的 DOM，这也就使得咱们开发网站的灵便度大打折扣，在这种状况下，同年：Ajax 火了。
AJAX 的呈现
为什么说 2005 年 Ajax 火了？因为 Ajax 技术并不是 2005 年呈现的，他的雏形是 1999 年。
1999 年，微软公司公布 IE5，第一次引入新性能：容许 javascript 脚本向服务器发动 HTTP 申请[这也就是明天万恶的 ActiveX 原型]。这个性能过后并没有引起留神，直到 2004 年 Gmail 公布和 2005 年 Google Map 公布，才引起宽泛器重
Google 做了什么事儿？
在 2005 年，Google 通过其 Google Suggest 使 AJAX 变得流行起来，他大略是这样的事件：
当初看来很常见的技术手段，过后迅速燃爆了技术圈，以此来实现：异步交互
这样既能减少用户的体验，又能代替掉页面局部的服务端代码，从此，AJAX 成为脚本发动 HTTP 通信的代名词，次年 W3C 也在 2006 年公布了 AJAX 的国际标准
总结：
随后各种 JSP ASP 的改进模板引擎、全新的交互方式也如雨后春笋个别涌现。并且以 JAVA 作为服务端也呈现了如 Struts、Spring、Hibernate 的老一代框架、采纳后端 MVC 的形式让构建 WEB 利用再一次更加健全, WEB 服务正在逐步由石器时代走向文化时代。
三、化繁为简 – 工业革命时代
时光啊一直地飞逝，前端后端也呈现了几个潮流。
前端倒退
挪动端
手机曾经倒退出了一些苗头，网页也辨别了 web 和挪动利用两种模式，但挪动端限度于过后手机行业的技术，倒退较慢。
Jquery 的呈现
呈现了十分风行的 JavaScript 库：jquery，可能疾速构建动静、美好的 web 利用，完满的封装了 Ajax，让开发者开发网页变得优雅。
SPA 的雏形
随着文化时代 Ajax 正式提出，加上 CDN 开始大量用于动态资源存储，于是呈现了 SPA（Single Page Application 单页面利用），Backbone EmberJS AngularJS 这样一批前端框架随之呈现，但以过后的配套技术来说，SPA 路线并不好走：例如 SEO 问题、SPA 过多的页面、简单场景下 VIEW 的绑定等，都没有很好的解决。
后端倒退
Struts、Spring、Hibernate 通过几年的倒退、SSM 这个明天被咱们说烂了的词、过后简直成了过后 JAVA 服务端的 首要选型，我想这也是为什么很多公司、或外包公司仍然保护这样一套架构的次要起因。
总结
这几年的飞速发展，为咱们节约了大量的经验、升高了开发者和开发过程的门槛，极大晋升了开发效率和迭代速度，我称之为 工业时代
经验
说进去你可能不信：大三快完结时实习求得的第一份工作，一个人断断续续开发 7、8 个月，就是钻研这些自技术栈，独立开发出一款 web 利用 微宝守业, 羞愧的说：
我的项目架构从文化时代 -> 走到最初的工业时代！一直的重构，一直的上线，拼命的学习，我很感激过后老板对我的信赖和共事对我的帮忙。
四、百家争鸣 – 技术大爆炸时代
时光啊他一刻不停，直到明天 — 技术只能用爆炸来形容。
前端爆炸
工业时代提出的 SPA 模型随着 NODE 的衰亡、服务端、各种工具、容器的飞速发展、前端 MVC MVVM 模式逐步清晰、前端涌现了相当一批优良的开源我的项目：
包治理：npm yarn
打包：grunt gulp
模块加载：RequireJS SeaJs
框架：VUE Angular React
hybrid：ionic weex react-native electron
预处理器：less sass
数据可视化：echarts hcharts
以及晋升用户体验的动画，让咱们更有“体面”
甚至前端也能够应用 Node 来构建本人简略的服务端、正在逐步解脱“客户端开发者”的角色
后端爆炸
go
更适宜面向服务器编程，以前你如果应用 C 或者 C ++ 做的那些事件，用 Go 来做很适合，例如、虚拟机解决、文件系统等，强如 docker Kubernetes（k8s）都是 GO 写的
python
像一门生物语言，目前看来更容易解决算法、人工智能、网络爬虫、运维方向
java
一款 20 多年的语言，一直的变强。涌现了很多高质量的库，几个有代表性的：
netty rebbitmq：轻松实现音讯队列
elasticSearch：轻松实现搜索引擎
spring-boot：面向配置，更加轻松的构建 web 服务端
spring-cloud、dubbo：轻松构建微服务
以及行将迎来的 强悍的 JAVA11
还有 继续集成 云服务 devops 等运维相干
总结
go 和 python 的呈现让咱们服务端开发者能做更多的事件，比方自动化运维、写中间件。逐步偏差全栈方向倒退。而 JAVA 20 多年来的生态圈子倒退，能帮忙咱们写出更强壮的服务。以及狠狠向咱们砸来的：人工智能、devops、云服务等技术，令咱们目迷五色，开源 成为了一种潮流，技术分享成了每个人都想做的事件，我称之为：技术爆炸的时代
经验
我近两年很懊恼：如何能力让前后端更加优雅的通信？
已经应用多种后端模板引擎直到齐全摒弃，后到 node 做代理、渲染 + grunt 进行数解决，之后逐步应用
vue + webpack ——> Rest API
这样如果不得不用 NODE 也只会成为 Rest 中的一员而不必通过 NODE 做繁琐的通信了。这种前后拆散的形式达到了称心的成果，前端不用再管后端的事件，后端？写好本人的服务就好了。
Part 3 聊聊前后拆散架构
前后拆散，始终是一个相当泛泛的问题，前后拆散到底好不好？没有相对的对，没有相对的错，业界就这个问题曾经强烈的探讨几年了. 呈现探讨的点在于：拆散当然是好的, 然而以什么样的服务须要进行前后拆分？拆分到什么粒度？前后端如何配合？
截图工夫: 2018-08-30 – Github
咱们随便在 Github 输出 前后拆散 关键字，看下搜寻的后果: 1K 的库 11k 的 Issues 足以阐明前后拆散的趋势，能够设想强烈水平，业界比拟有名的探讨：Web 前后端拆散的意义大吗？，值得一提的是：前排对于这个问题探讨比拟粗浅的大部分都是 全栈工程师。因为全栈对全局的理解绝对比单纯做前端、后端全局观念更强一些，思考的问题更多一些。
筛简历引发的思考和剖析
后端职位的怪圈
在公司的简历库顺手截几个部分的图，近两年面试过很多的 1-3 年 java 开发者，在筛选简历和面试过程中，也发现了几个问题：相当多一部分 javaer 技术栈上总是多了那么个 HTML ajax jquery bootstrap easyUi，看起来很唐突，如果面试提到了前端技术栈，根本没有能答的很好的，甚至有的人连 原型链 都不晓得。 这也是大部分人对全栈的误会，其实我是不太感冒这样的简历的，因为没有什么亮点，技术栈不是写的越多越好，总结起来：他们对前端的把握很根底，勉强能胜任一些业务上的工作。那为什么这么多人都把握一些前端技术呢？我剖析可能有三点：
思考起因：
- 培训机构的衰亡，机械化的教学
- 求职者本身的趣味
- 一些公司的技术栈不全，对技术没有谋求，大部分用的几年前的架构，前后业务耦合很大，市场缺口大
剖析
因为我也保护过几个月的敏感我的项目，深有体会，只写服务端的人是无奈胜任这项工作的，
如果少数的 开发者 这样的简历，能够揣测：当初的 IT 行业中前后端糅杂一起的架构还是存在、并且有一个量级，这导致他们 不得不 寻找一些懂得一点前端技术的人来开发我的项目，缩小沟通的老本，放慢我的项目的进度，这也就催生了很多所谓的 web 开发培训机构。
你问我当年保护的开心吗？一会通知你。
什么是前后拆散
前后端拆散并不是什么新鲜事，到处都是前后端拆散的实际。然而一些历史我的项目在从一体化 Web 设计转向前后端拆散的架构时，不可避免的会遇到各种各样的问题。因为层出不穷的问题，甚至会有团队质疑，一体化好好的，为什么要搞前后端拆散？说到底，还是技术和思维形式没转变过去。
一体化模式其实在上一开篇：纵观历史演变 中曾经提到过了，不在赘述。
前后拆散看起来应该是这样的：
前后拆散就是在 架构档次 上 构建我的项目或对现有的我的项目 客户端 服务端 分来到，缩小前后端代码的耦合度，大家统一认同的前后端拆散的例子就是SPA(Single-page application)，所有用到的展示数据都是后端通过 JSON 但不仅限于 JSON 的形式提供的，前端只管展示, 提供更好更绚的交互，后端只管提供更强壮的高可用服务。
千万不要有先写我的项目，写完再重构的想法，我的项目初期能一步到位最好，何必再去重构，而后不得已摈弃一些曾经写完的组件、库节约人力呢？
前后拆散解决了什么问题
每个人各尽其职
好的开发者是可与不可求的，若寻找一个 优良的 full_stack 更是难，从校招进行造就也不太理论，招一个能力个别的程序员，技术驱动性比拟差，甚至拖慢产品迭代。拆散开来咱们就能够专一于 前端 、 服务端 畛域去寻找业余的人才。
解耦
前端后端代码大量耦合代码看起来是这样的：
看看简略例子吧：
//(node 端解决)
if (is_weixin()) {
init([
'api',
'image',
'xxx',
'...',
], function () {<%- doSomeGloble %>});
} else {
}
// 接管 node 端一些数据
let blogs = <%- blogs %>;
let users = <%- users %>;
这还不是 JAVA 模板 而是绝对轻量、优雅的 NODE 的 EJS 渲染的，这还好，我见过更令人好受的代码，常常为了一个问题要回头看 N 多代码，这里就不写了。
那么前后拆散如何让它们解耦变得更清晰？前面会联合服务端对立补充。
什么我的项目不适宜前后拆散
blog、文档
你说你搭建一个 博客、API 文档零碎 这种小我的项目，一个人就能够开发。搞了一个前后拆散，须要拆散部署。又减少了 SEO 的复杂度，减少了开发的周期、减少了用户部署的难度，何必呢？当然，如果只是技术实际的一种学习形式，还是欢送的。
前后拆散带来的问题，如何解决？
沟通老本问题
前端妹子：哥，获取全副博客调哪个接口？
哦，昨天不是发你文件了吗
前端妹子：我找不到了????
哦，等下吃晚饭发你啊
前端妹子：哥，产品提出依据手机壳主动换主题的需要，你有接口吗？
… 我看看 … 应该 … 没有！可能须要 Python 的老哥反对！你去找他要吧
前端妹子：哥，你依据 TAG 获取博客的接口写完了没？接口是啥？我好渲染数据啊
没等等 ……
这显然是不标准的，咱们冀望的是前端后端先约定一个接口协议，后端没实现时，前端本人 mock 测试数据，前端找不到接口的时候，间接查看 API，依据这个接口协议咱们前后端对立编程，那么咱们如何解决呢？
如何升高沟通老本？
后端数据服务化，走对立的 REST 接口标准输入，升高前后端接口定义的沟通老本。防止“口头阐明”的形式。
什么是 RESTful API？
所以 RESTful API 就是 REST 格调的 API。那么在什么场景下应用 RESTful API 呢？在当今的互联网利用的前端展现媒介很丰盛。有手机、有平板电脑还有 PC 以及其余的展现媒介。那么这些前端接管到的用户申请对立由一个后盾来解决并返回给不同的前端必定是最迷信和最经济的形式，RESTful API 就是一套协定来标准多种形式的前端和同一个后盾的交互方式。
我通常用 swagger + mock 平台生成规范的 RESTful API，同时也反对扩大多个编程语言例如：Go Python
SEO 问题
以 vue + webpack 的 SPA 为例，没有了后端模板返回的 HTML，前端渲染并不被搜索引擎的爬虫接收。在日后实战 SEO 之前先艰深渲染呗爬虫辨认的区别：
seo 实质是一个服务器向另一个服务器发动申请，解析申请内容。但一般来说搜索引擎是不回去执行申请到的 js 的。也就是说，如果一个单页利用，html 在服务器端还没有渲染局部数据数据，在浏览器才渲染出数据，而搜索引擎申请到的 html 是没有渲染数据的。这样就很不利于内容被搜索引擎搜寻到。所以服务端渲染就是尽量在服务器发送到浏览器前 页面上就是有数据的。
以博客为例简略聊聊:
- 动态服务
<div> 我是注释 1 </div>
<div> 我是注释 2 </div>
<div> 我是注释 3 </div>爬虫间接抓到 html 解析 – 生成索引
- 传统后端渲染
@RequestMapping("/index")
public String index(HttpServletRequest request,HttpServletResponse response){return "welcome";} 这里就比拟有意思了，比方咱们关上的网址是:
http://host:port/index
理论充当 Controller 的是 服务端，服务端间接返回渲染好的网页给你，爬虫拿到的也是一样，所以 SEO 没啥太大的问题。
- 前后拆散 SPA
let blogs = [];
this.axios.get('/index, {})
.then(res => {blogs = res.data;})
.catch(err => {console.error(err);
});
<!-- 前端模板渲染 dom-->
<div v-for="(item, index) in blogs" :key="item"> 同样咱们输出http://host:port/index
留神：SPA 通常有本人的路由策略，这也就是前端 MVC MVVM 中的 第一个 M
一个典型的 SPA 站点
咱们输出网址先到了这个页面，而后再去异步申请服务器，再由前端页面渲染，又是 单页面服务 如果咱们不做任何解决，那么你将被各大搜索引擎摈弃。
如何解决？
只有做 SEO 的产品就要做服务端渲染, 如果你对 SEO 需要有，但要求并不高，仅局部页面、能够曲线救国
nodejs 呈现之前有两种解决形式，一是做一动一静两套页面，服务器判断申请来自蜘蛛就出现动态页，否则出现动静页；二是服务器架设虚构浏览器软件，申请过去了先让虚构浏览器跑一遍，再将失去的动态页面返回给客户端。这两种形式在大型项目上都有性能问题。
有了 nodejs 后支流做法是前后端同构计划，即一套代码在浏览器端和 node 端都能够运行，从而能够先在 node 端申请数据渲染模板，而后将渲染后果返回给浏览器最终出现。感兴趣能够看看
Vue 的 SSR 计划
Angular 的 SSR 计划
如何更粗疏的钻研 SEO 当前再说
跨域
因为采纳前后端拆散部署，天然不在一个端口，不在一个端口必然跨域，不过这对当初的技术手段来说齐全不是问题
开发模式
为了更快更好的开发，dev 下个别采纳 node 做代理层，解决跨域，简直无障碍开发，而且能够轻松切换环境。
部署模式
部署个别不依靠 node 进行部署，通常咱们公布到 HTTP 服务器，与服务端进行通信，通常应用 nginx 进行正向代理。
Part4 前端理解多少？
技术栈的抉择
首先咱们构建前端架构须要对前端生态圈有所有理解，并且最好带有肯定的技术 前瞻性，好的技术架构可能日后会不便的扩大，缩小重构的次数，即便重构也不须要大动干戈，我通常选型技术栈会参考以下三点：
一、提出本身业务的需要
- SEO 是否十分重要？
- 次要面向：挪动端还是 pc 端？
- 是否有开发 app 的布局？
有了这样的问题咱们能够带着问题去重点选型一些这写问题技术计划比拟成熟的技术栈。
二、本身是否成熟，文档是否敌对
这里举一个以前开发过程中理论遇到的，过后为了优化用户体验，节俭开发效率 选型了一款 MVVM 轻量框架，惋惜过后没有决定权，CTO 选型了 avalon
过后之所以没有抉择 backbone，次要是因为没有成熟的中文文档，思考到团队的流动性和上手性临时没做思考，最终抉择了 司徒正美的 avalon 过后来说还是比拟前卫的，也有一些以去哪网为首的大公司都在用。咱们过后用的时候 avalon2 刚出不久，间接用的 2.0，应用过程也呈现了一点问题：文档离散，这一块那一块，存在后置性，生态少，扩大性价比不高，有时候遇到匪夷所思的 bug 寻找起因翻了几遍 demo、文档 可能会找到答案，没有重点标识。当然就过后来说的确是给咱们晋升了局部开发效率，然而我可能过后更偏差 Angular 或 vue 的。因为他们有无以伦比的生态圈和各种问题的技术计划以以及欠缺的开发者文档，值得一提的是 avalon 的作者是兼职保护的，如果全栈经营的话，我置信远比当初更好，看一看 avalon 的源码也会对本人有不少的晋升。对于生产的技术选型要更加审慎。
三、理解其生态系统
上文提到了生态系统，以我比拟罕用的 vue 来举例，vue 倒退至今仅官网为咱们提供了以 vuex、vue-router、vue-loader、vue-cli、vuepress、vue-devtools、vue-ssr 为首的 89 个开源我的项目，包含有数的 vue 相干的 UI 库，vue 插件 甚至是近两年淘宝提供的 Hybrid：weex 的反对
截止明天 github 开源的 与 vue 相干的我的项目多达 167,752 个，与 angular 相干的多达 416,811 个，与 react 相干的 多达 594,272 个。
统计工夫 2018-09-01
我想有了这样的生态反对，齐全能够满足咱们中小我的项目的 95% 以上的需要，至于比拟哪个更强是没有意义的。
因为比拟相熟让我斗胆擅自抉择 vue 作为咱们的 SPA 主架构
四、画出咱们冀望的前端基础架构模型
因为咱们上一章选型了 Vue，如果只思考前端咱们最后的想法: 技术栈大略是这样的：
通过 node 和 webpack 的反对 把 vue 组件 build 打包成传统元素，公布到 http 服务中，申请后端服务。
随后可能是这样的：
随着目前支流第三方库的越来越多和技术的尝鲜、客户端的需要、或被动[不得不用]、或被动的去援用了 babel less sass *.loader 和 hybrid 等组件库。
再起初的技术栈须要咱们依据真正踩坑之后才会逐步完善
可能是 polyfill 懒加载 xss protobuf 等 针对 浏览器兼容 、 速度优化 、SEO、 通信协议 等具体问题。所以，后期能够不必过多思考，咱们只有晓得：这个问题咱们是能够解决的，然而当初能够先不去思考，有些同学，太过于“ 完美主义 ”以至于想法不错，但动起手来做了几天就不做了， 完美主义害死人。
理解 Webpack
WebPack 能够看做是模块打包机器，它能够剖析你的我的项目构造，找到 JavaScript 模块以及其它的一些浏览器不能间接运行的拓展语言：Stylus、Scss、less、TypeScript、CoffeeScript 等，并将其转换和打包为适合的格局供浏览器应用。比拟罕用的还能够通过 webpack-dev-server 进行开发模式的 热更新
WebPack 是一种模块化开发的计划
当 webpack 解决应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中蕴含应用程序须要的每个模块，而后将所有这些模块打包成一个或多个 bundle
webpack 通过 loader 能够反对各种语言和预处理器编写模块，最初打包为一个（或多个）浏览器可辨认的 JavaScript css 文件
目前反对的 loader 列表
理解 ES6
官网说法
ECMAScript 6（简称 ES6）是于 2015 年 6 月正式公布的 JavaScript 语言的规范，正式名为 ECMAScript 2015（ES2015）。它的指标是使得 JavaScript 语言能够用来编写简单的大型应用程序.
科普
很多人总是搞不清楚 ES 这些货色，这里大白话讲讲：
他们的先后顺序是：ES5、ES6(ES2015)、ES7、ES8
在 2015 年 6 月 ES6 的第一个版本公布，正式名称就是《ECMAScript 2015 规范》（简称 ES2015）算是 2011 年 ECMAScript 5.1 之后的 6.0 版本
2016 年 6 月，小幅订正的《ECMAScript 2016 规范》（简称 ES2016）[因为改变小，其实他是 6.1 版本，但总有人违心叫它 ES7，不规范的]
2017 年 6 月公布 的《ECMAScript 2017 规范》（简称 ES2017）[因为改变小，其实他是 6.2 版本，但总有人违心叫它 ES8，不规范的]
就像 Kubernetes 人们开他起了一个 K8S 的名字 (K 和 S 两头有 8 个单词)，他是不规范的
理解 Babel Traceur
Babel、Traceur 是一个编译 JavaScript 的平台，它能够编译代码帮你达到以下目标：
JavaScript.next-to-JavaScript-of-today compiler
明天就应用将来的 JavaScript
截止公布日期 (2018-09-04)，没有一款齐全反对 ES6 的 JavaScript 代理（无论是浏览器环境还是服务器环境），所以热衷于应用语言最新个性的开发者须要将 ES6 代码转译为 ES5 代码。
让你能应用最新的 JavaScript 代码（ES6，ES7…），而不必管新规范是否被以后应用的浏览器齐全反对；
ES7 作者齐全没精力看，不过 Bable 逐步代替了 Google 的 Traceur 成为支流了，我是个俗人，所以我选 Bable
理解 Sass Less Stylus
Sass 是不是违反了中国的广告法了？？
Sass、Stylus 和 Less 之类的预处理器是对原生 CSS 的拓展，它们容许你应用相似于 variables, nesting, mixins, inheritance 等不存在于 CSS 中的个性来写 CSS，CSS 预处理器能够这些非凡类型的语句转化为浏览器可辨认的 CSS 语句。
- 一张表格比照三语言
| 语言 | 实现 | 个性 | 赋值 | 缩进 |
|---|---|---|---|---|
| Sass | Ruby | 变量 $ 结尾 | $var: value | 不须要 |
| Less | JavaSript | 变量 @结尾 | @var: value | 不须要 |
| Stylus | NodeJs | 不能应用 @结尾 | var:10 | 都能够 |
你当初可能都曾经相熟了，上文讲 WebPack 讲过：webpack 里应用相干 loaders 进行配置就能够应用了，以下是罕用的 CSS 解决 loaders:
Less Loader
Sass Loader
Stylus Loader
本人去找：loader 列表
像：哪种语言更好、应用的更多、更简略 容易引起争议的 博主不想探讨，看本人爱好
理解 Electron
一个能够应用应用：JavaScript, HTML 和 CSS 构建跨平台的桌面利用的框架，也算 hybrid 的一种，次要场景是 PC 端，没啥好说的。
值得一提的是 Visual Studio Code、Atom、GIthub Desktop 都是基于此构建的，有时候按 CMD + option + i 有惊喜哦
基于 Electron 开发的 APP 列表
Part5 疾速构建标准的我的项目骨架「VUE」
初步搭建脚手架
- Tips
任何不错的开源我的项目都有 project-cli 脚手架、咱们用它生成往往能 疾速 配制出最佳的、现实的脚手架
我通常应用 cli 生成我的项目骨架再在之根底上进行集体批改。
什么是 CLI
命令行界面（英语：command-line interface，缩写：CLI）是在图形用户界面失去遍及之前应用最为宽泛的用户界面，它通常不反对鼠标，用户通过键盘输入指令，计算机接管到指令后，予以执行。也有人称之为字符用户界面
顾名思义 XXX-CLI 就是应用命令行生成的 XXX 程序。之前写过一款 基于 nodeJs 制作共性 CLI 的教程
如何用 node 开发本人的 cli 工具并公布到 NPM ，想具体理解制作流程的能够简略看看。
vue-cli
截止 2018-09-02 vue-cli 最新版本为 3.0
vue 中文生态十分欠缺，咱们间接去官网看看：
https://cli.vuejs.org/zh/
vue-cli2 和 vue-cli3 的比照
很遗憾，vue-cli-3 是 2018-08-11 进去的，而我的论坛早在之前就着手搭建了 cli-3 耽搁了我一些工夫，前面也会提到
简略看看了看 vue-cli3 的新个性：
- 能够生成 pwa
- 反对 UI 界面勾勾选选就能够了
- 兼容 cnpm 了
- 搞了一套本人的 vue-cli-service 如下：
我这两天不忙的时候就在思考我的项目兼容 vli-3 然而起初废了很多工夫，成果仍然不现实，我回滚了代码发表放弃了。
鉴于应用 cli-3 并没有对我的我的项目有性能上的晋升，反而翻遍了我的很多成熟的基础架构，为工夫老本思考，我决定还是应用 cli-2 进行开发，大体目录构造都是一样的。
vue-cli 的装置
装置前应留神前提条件，避免浪费不必要的工夫。
Vue CLI 须要 Node.js 8.9 或更高版本 (举荐 8.11.0+)。(如果你用的和我一样 也是 cli-2 那么不须要如此新的 nodeJs )你能够应用 nvm 或 nvm-windows 在同一台电脑中治理多个 Node 版本。
不将远离了，官网比我讲的好得多。
能够应用 yarn 或 npm 来装置
npm install -g @vue/cli
# OR
yarn global add @vue/cli我用 NPM 来从新尝试一次 (对 npm 速度示意不现实的 能够尝试淘宝的 CNPM 不要适度依赖 cnpm)：
localhost:~ Venda-GM$ sudo cnpm i @vue/cli -gTIPS
npm 中 install 能够写成 i , -g 放哪都行，–save 能够写成 -S , –save-dev 能够写成 -D
看到这个画面，装置实现了。
测试一下查看一下版本是不是正确，ok 创立我的项目：
vue create new-bee拉取 2.x 模板 (旧版本)
Vue CLI 3 和旧版应用了雷同的 vue 命令，所以 Vue CLI 2 (vue-cli) 被笼罩了。如果你依然须要应用旧版本的 vue init 性能，你能够全局装置一个桥接工具：
npm install -g @vue/cli-initvue init 的运行成果将会跟 vue-cli@2.x 雷同
vue init webpack my-project #这样来生成一个 *cli-2* 我的项目应用 vue-cli-2 生成我的项目
vue init webpack new-bee上面是我创立我的项目我所选的选项：
略微讲讲上面三个：
- vue build 的形式
举荐应用 运行时 + 编译时，通常须要 webpack 编译 .vue 模板。
- 是否抉择事后设定的 Eslint
并是不每个人都适宜的，有的要求过于严格，我本人有一套成熟的，代码在这里 , 就用本人的了，当然能够基于它做一些删减。
- 它要帮咱们执行 install
如果你有一个好的 socket 终端代理，能够用这个，否则能够抉择 No 本人用 cnpm 执行
初窥目录构造
让咱们来看看 vue-cli2 主动生成的我的项目目录，我打上标签，为可能不太了解的同学简略形容一下
这次咱们重构的次要目标是标准、更适宜多模块多人合作、而不是为了让它看起来更简单，本文的我的项目构造、esLint 改进、等都是通过我的项目小组重复的斟酌决定的，有肯定的生产价值。
杞人忧天：为 electron 做好筹备
cli 生成的我的项目 src 上面间接就是源码，然而为了思考当前应用 electron 咱们再用 renderer 包裹一下，标准一点。
能够参考一下 electron-vue
兼容 Electron 的源码目录
tips: 上述截图 github 树形目录的插件是 octotree 也能够在谷歌商店间接搜寻装置，看源码省去不少工夫。
- 先不建设 electron 的 main 文件夹 和 index.ejs 须要增加依赖，目前临时用不到。
别忘了改一下 webpack 相干的门路问题
加上 renderer 的门路
app: './renderer/src/main.js'@ 的门路也要在 webpack 进行批改，否则会不找组件
须要改下 webpack alias [别名] 配置
改之后的样子
alias: {'@': resolve('renderer/src'),
}容器级的目录
在 组件目录 (components) 同级建设 容器 (container)：容器外面的各个模块分来到，这样能够使我的项目 模块 看起来更加清晰。如果十多人合作的我的项目又能很好地对工作区划分，正当的建设路由，防止不必要的抵触。
以目前的论坛我的项目为例
路由目录的调整标准
在 /router 下为 /container/blog 建设 blog.js
const Blog = () => import ( /* webpackChunkName: "blog" */ '@/container/blog/index')
/*
所有 container/blog 目录下的门路都配置在此路由 children 下，防止凌乱
*/
let routes = [{
path: '/blog',
name: 'blog',
component: Blog,
children: [{
path: 'blogdemo',
component: Blog
}
]
}]
export {routes}
// 留神
/* webpackChunkName: "blog" */
// 是为了前面的路由懒加载，前面会讲，不懂没关系，当初能够疏忽
- 主动生成的 index.js 主路由是这样的
- 毛病：
太繁多，咱们不可能所有的路由都写在外面作为 children，看起来十分凌乱，开发调试很难解决，多人合作还很容易引起抵触。
咱们尝试将 blog.js 引过来
先将 blog.js export 的路由引过来，起一个别名避免抵触
import {routes as blogRoutes} from './blog'因为可能有 N 多个路由模块，咱们将 routes 拆分
主动生成的是这样简略的：
// 间接导出路由
export default new Router({
routes: [
{
path: '/',
name: 'HelloWorld',
component: HelloWorld
}
]
})咱们拆分成这样：
// 定义根底路由
let route = [
{
path: '/',
name: 'HelloWorld',
component: HelloWorld
}
]
// 以此类推能够不便的链接更多路由
route = route.concat(blogRoutes)
// 导出
export default new Router({
routes: route,
linkActiveClass: 'active'
})回过头来，咱们为 blog/index.vue 增加一些内容，测试一下：
<template>
<div class="Blog">
<h1>{{msg}}</h1>
</div>
</template>
<script>
export default {
name: "Blog",
data() {
return {msg: "Welcome to Your Blog Page"};
}
};
</script>测试一下
首先
npm install嫌慢能够应用淘宝的 cnpm 我以前的文章讲过
npm run dev依照提醒在浏览器输出：http://localhost:8080/#/blog
vue-cli2 webpack 生成的我的项目是反对 热部署 的，所以很多配置不须要本人从零开始配置，这也是我心愿大家应用 CLI 的起因，省去了一些工夫。其余 login 等一些模块 依照这个模式写就能够了。
谈谈 eslint
集体感觉 esLint 不论是在集体我的项目还是团队合作中，都是有价值的，它能够让本人、团队的代码格调标准化。当初 esLint 甚至能够预测你的代码是否可能会有问题。倡议能够制订一些规定，开发时通过你的 IDE(集成环境)：idea、WebStorm、vscode、之类的插件配合检测，eslint 打包检测编译不通过的那种十分严格的初期还是不要尝试了。
我过后参考 airbnb 调整的配置，通过一年多的我的项目实战逐步调整，目前还算比拟正当，esLint 配置规定代码在这里。
本章代码在这里
你甚至能够再 commit 里看到本章循序渐进的革新过程
Part 6 打磨前端架构
axios
应用了 vue 的你，发现 Vue 竟然不能发申请，于是你 Google 了下，发现能够用 Vue-Resource。
你去问他人 Vue-Resource 怎么样，他说不要用 Vue-Resource，因为 Vue-Resource 官网曾经进行保护了，你应该用 Axios、或者 fetch。然而咱们想拥抱 ES6 排除掉了 ES5 的 fetch（当然也有 ES6-fetch），这里咱们应用 Axios！
Tips
这里呢也科普一下：什么时候依赖须要放到 dependencies、什么时候依赖须要放到 devDependencies：
devDependencies：顾名思义，仅在开发（dev）模式下如：webpack.、.loader、eslint、babel、打包后部署时齐全用不到的、仅在开发须要 编译、检测、转换 的放在这里。
dependencies：例如：axios、chart、js-cookie、less、lodash、underscore 等运行时的库或工具类等相干依赖咱们要放在这里
不过根本不必放心，官网都会提供 start 阐明，然而咱们要大略明确意思，不要机械般的 copy。
引入 Axios
- 间接玩最新的
2018-09-28 截图 npmjs.com
- 增加依赖
"dependencies": {"axios": "^0.18.0"}
基于上一章内容, 别忘了从新 npm i 下载一下
还记得咱们主动生成的 vue 主页面脚本 main.js 吗？
封装 axios
咱们在 src/renderer/utils 建设一个 request.js 在这个申请脚本中，对 Axios 做一些必要的封装，大略内容是用 拦截器 axios.interceptors 对申请和响应做些拦挡，定义一下 API 的前缀，解决一些常见的 HTTP 状态码。
- interceptors 文档
我尽可能的为大家写了具体的正文。
// src/renderer/utils/request.js
import axios from 'axios'
// 这里个别指后端我的项目 API 的前缀，例如 /baidu/*/*/1.api /mi/*/*/2.api
const BASE_API = ""
export function axiosIntercept(Vue, router) {
const axiosIntercept = axios.create({baseURL: BASE_API})
//http request 拦截器 个别用来在申请前塞一些全局的配置、或开启一些 css 加载动画
axiosIntercept.interceptors.request.use((config) => {
// 判断是否存在 token，如果存在的话，则每个 http header 都加上 token
// if (store.getters.accessToken) {// console.log(store.getters.accessToken)
// config.headers.Authorization = `token ${store.getters.accessToken}`;
// }
//todo: 加载动画
// 若有需要能够解决一下 post 亦或扭转 post 传输格局
if (config.method === 'post') { };
return config;
}, function (err) {return Promise.reject(err);
});
//http response 拦截器 个别用来依据一些后端协定非凡返回值做一些解决，例如：权限方面、404... 或敞开一些 css 加载动画
axiosIntercept.interceptors.response.use(function (response) {
// todo: 暂停加载动画
return response;
}, function (err) {
// 捕捉异样
if (err.response) {switch (err.response.status) {
case 401:
// do something 这里咱们写完后端做好束缚再欠缺
}
}
return Promise.reject(err);
});
return axiosIntercept;
}
大家还记得咱们用 vue-cli 生成的 vue 主页脚本 main.js 吧，这里咱们须要对 Axios 和 Vue 做一个耦合。
// src/renderer/main.js
import axios from 'axios'
import {axiosIntercept} from './utils/request'
// 将 Axios 扩大到 Vue 原型链中
Vue.prototype.$http = axiosIntercept(Vue)这样咱们在写业务逻辑，间接在 Vue 的上下文中 应用 this.$http 来发送申请。既实现了拦挡、又实现了状态的共享。
知其然，知其所以然
- 这样做的意义在哪？
节俭代码量，让代码更加易读
- 为什么？
扩大到原型链，使 Axios 运行时共享 Vue 原型链的内容，缩小了很多指代 Vue 的长期变量
- 举个栗子
传统状况
import axios from 'axios'
new Vue({
data: {user: ""},
created: function () {
// 此时作用域在 Vue 上, 缓存起来, 要依赖此变量
let _this = this;
axios.get("/user/getUserInfo/" + userName).then(res => {if (res.data.code === 200) {
// 此时作用域在 axios 上，拿不到 vue 绑定的值，只能借助方才缓存的_this 上下文
_this.data.user = res.data.user
}
});
}
})
代理之后
new Vue({
data: {user: ""},
created: function () {
// axios 成为了 vue 的原型链一部分，共享 vue 状态。this.$http.get("/user/getUserInfo/" + userName).then(res => {if (res.data.code === 200) {
// 留神，axios 回调，应该尽量应用箭头函数，能够继承父类上下文，否则相似闭包，还是无奈共享变量、// 更优雅了一些
this.data.user = res.data.user
}
});
}
})
不懂 prototype 能够翻翻我以前写的文章
proxy
先简略弄一下，为前后拆散打个小铺垫
webPack
- webPack 的别名
resolve: {extensions: ['.js', '.vue', '.json'],
alias: {'@': resolve('src/renderer'),
}
},为了应用起来更加优雅，能够为每个罕用的目录都建设别名
resolve: {extensions: ['.js', '.vue', '.json'],
alias: {
'vue$': 'vue/dist/vue.esm.js',
'@': resolve('src/renderer'),
'assets': resolve('src/renderer/assets'),
'components': resolve('src/renderer/components'),
'container': resolve('src/renderer/container'),
'utils': resolve('src/renderer/utils')
}
},生产和开发的跨域问题
dev 是开发时启动的指令
build 是预公布时 webPack 打包的指令
假如笔者只是一个前端，通常呢，在开发调试过程当中，无奈防止须要与后端的同学进行 API 的对接，那也就难免会呈现跨域问题。当然传统 javaWeb 不须要跨域，(ip 域 端口 任何一个不同皆为跨域) 在 DEV 模式调试中，咱们都是尽量抉择前端环境躲避跨域问题，而不会去额定搭建 nginx 或更改后端代码。
跨域只是针对 JavaScript 的，因为开发者认为浏览器上的脚本是不平安的。
既然咱们的 vue 我的项目是 node 全家桶，依附 node、webPack 编译 咱们间接配置 node 的 proxyTable 作为开发的代理器，这样最简略，顺次配置，团队受害。
cnode 掘金 社区 API 举例
https://cnodejs.org/api
上边 cnode 的 API 是能够随便调用的，因为后端做了解决。
看看掘金的：
https://xiaoce-timeline-api-m…
申请一下，不出意外浏览器做了跨域报警。
哦，咱们适配一下 node 代理
官网例子在这：
https://vuejs-templates.githu…
扩大一下 proxyTable：
proxyTable: [{
// 拦挡所有 v1 结尾的 xhr 申请
context: ['/v1'],
target: "https://xiaoce-timeline-api-ms.juejin.im",
cookieDomainRewrite: {// 不必 cookie},
changeOrigin: true,// 重点，此处本地就会虚构一个服务替咱们承受或转发申请
secure: false
}],
再次发送申请。
- 欢快的拿到了数据
这样，前后拆散的我的项目能够这样借助 swagger 测试接口，不须要骚扰任何人。实现本人的业务逻辑，简略实现一点。
代码:
// blog/index.vue
<template>
<div class="Blog">
<h1>{{msg}}</h1>
<div v-for="(blog,index) in blogList" v-bind:key="index">
<h3 >
<a :href="`https://juejin.im/book/`+blog.id" >
<span>{{blog.title}}</span>
</a>
</h3>
</div>
</div>
</template>
<script>
export default {
name: "Blog",
data() {
return {
msg: "掘金小册一览",
blogList: []};
},
created() {this.getBlog();
},
methods: {getBlog() {this.$http.get("/v1/getListByLastTime?src=web&pageNum=1").then(res => {this.blogList = res.data.d;});
}
}
};
</script>公布
- 扫盲
写完代码之后部署到线上，是不会在线上 clone 代码之后 Npm run dev 的????，那样会有太多太多的垃圾依赖，为用户带来了灾难性的网络申请，通常借助 webPack 打包之后公布到服务器的 web 服务当中。
运行
npm run build
打包目录是之前配置的 webpack
好了，很多人间接双击 index.html 是不行的。
Tip: built files are meant to be served over an HTTP server.
Opening index.html over file:// won’t work.
须要 http 服务启动，能够扔到本地或服务器的 nginx、apache、tomcat 等容器测试，我通常应用 python 启动一个 http 服务来运行（脚本地址）、当然, 本人 ide 反对 http 启动也能够。
生产中的跨域
生产当中，因为前端后端必然不同端口，防止跨域，通常应用 nginx 的正向 / 反向代理作为跨域的伎俩。（并非负载平衡，两个概念）
server {
listen 80;
server_name localhost;
location ^~ /v1 {
proxy_pass https://xiaoce-timeline-api-ms.juejin.im;# 代理。proxy_set_header X-Real-IP $remote_addr;# 转发客户端实在 IP
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
} 简略配置一下就能够了，不多讲，前端同学理解一下就能够了，nginx 无能的事件还有很多。
API 的规范化
你是否为了找某一个业务的接口头痛
你是否还在应用全局搜寻找本人的接口
你是否某一个接口不同组件反复写了屡次
整顿一下本人的接口吧，像上文的 router 一样参差的划分吧。
/renderer 下建设一个 api 的文件夹
webpack.base.conf.js 增加一条 api 的别名，不便咱们日后大量调用
'api': resolve('src/renderer/api')咱们建设 /renderer/api/juejin.js
import axios from 'axios'
let Api = Function()
Api.prototype = {getBlog(page, fn) {axios.get(`/v1/getListByLastTime?src=web&pageNum=${page}`).then(res => {// if (res.data.code === 200) {fn(res.data)
// }
}).error()}
}
export default new Api()
批改一下咱们方才 /blog/index.vue 的 Axios 申请：
- 先引入 api
import juejin from "@/api/juejin";注掉之前离散的 axios，应用从 api 中定义过的 XHR 申请数据。
getBlog() {// this.$http.get("/v1/getListByLastTime?src=web&pageNum=1").then(res => {
// this.blogList = res.data.d;
// });
juejin.getBlog("1", response => {this.blogList = response.d;});
}
Part 7 疾速构建网站布局
本文为不便讲述重构去除了 Element、vux 库，用了最近比拟火的 bulma 轻量、快捷、易读。
我的项目截屏
Layout and Components
Layout
首先，似上图，咱们思考把一个小型网站拆成三局部：页头(Header)、内容(Content)、页脚(Footer) 这简直每个网站内都必须有的，通常把万年不变的：页头(Header)、页脚(Footer) 制作成 Layout 不便通用。
Components
再把内容 (Content) 依据业务进行拆分成 组件(Components)
如上图：Header 和 Content：Header 其实没有拆分的必要，没有能够重用的组件，而 Conntent 是必须要拆分的布局元素。因为动静网站 Conntent 随着内容的变动而变动，内容多，可重用的货色的概率越高，须要把能重用的货色提炼进去
1、节俭代码、进步代码浏览性
2、便于批改（比方更新广告）
开始写代码
接着咱们的 第二章上传的源码 开始，基于它持续欠缺小网站布局和组件化。
值得一提的是：本系列教程一章追随一章并且每一章能够独立运行，章与章之间完满连接，没有“忽然呈现”的代码段。不会给老手无从下手的感觉，如果那你对代码生疏，那你该认真翻翻往期文章了。你能够基于上一章逐渐写代码，也能够下载本章简略预览代码。
- 引入 bulma 款式 CDN
vim new-bee/index.html
<!-- font -->
<link href="//cdn.bootcss.com/font-awesome/4.7.0/css/font-awesome.min.css" rel="stylesheet">
<!-- css -->
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bulma/0.6.0/css/bulma.min.css">
- 新建 Layout 目录
vim new-bee/src/renderer/components/layout- Layout 目录下建设 Header.vue 模板组件
这个组件专门写头部的内容，最好配合栅格尽可能写出简略的响应式组件
<template>
<div id="bee-header" element-loading-text="正在致力申请 github..." element-loading-background="rgba(0, 0, 0, 0.8)">
<!-- 遮罩 -->
<div :class="loading ? `modal is-active` : `modal`" style="background-color: #ffffff36">
< img src="https://img.actd.tw/images/2018/11/17/ez-4-05f4bba41fef" style="width: 300px" alt="">
</div>
<div class="is-underline">
<div class="container">
<nav class="navbar">
<div class="navbar-brand">
<a class="navbar-item" >
< img src="https://img.actd.tw/images/2018/11/17" alt="Bulma: a modern CSS framework based on Flexbox" width="92" height="28">
</a >
<div class="login-before is-hidden-mobile" style="padding-top: 5px;">
<a class="navbar-item is-hidden-desktop" href="" target="_blank">
<span class="icon" style="color: #333;">
<i class="fa fa-lg fa-github is-size-2"></i>
</span>
</a >
</div>
<div class="navbar-item is-hidden-desktop">
<div class="field has-addons" ><div class="control" ><input type="input" class="input" name="email" placeholder="搜寻一下" required="required" style="height: 36.4px;width:130px"><input type="hidden" name="redirect" id="name" value="/fr/#thanks"></div><div class="control" ><input type="submit" class="button is-warning" value="GO"></div></div>
</div>
<div class="navbar-burger burger" data-target="navMenuDocumentation" >
<span></span>
<span></span>
<span></span>
</div>
</div>
<div id="navMenuDocumentation" class="navbar-menu">
<div class="navbar-start">
<div class="navbar-item has-dropdown is-hoverable">
<a class="navbar-link is-active">
发现
</a >
<div class="navbar-dropdown">
<a class="navbar-item" type="珍藏集">
珍藏集
</a >
<a class="navbar-item" type="徽章">
徽章
</a >
<a class="navbar-item" type="排名">
排名
</a >
<a class="navbar-item" type="职场生存">
职场生存
</a >
</div>
</div>
<a class="navbar-item" href="https://bulma.io/expo/">
<!--<span class="bd-emoji">⭐️</span>-->
专栏
</a >
<a class="navbar-item" href="https://bulma.io/expo/">
<!--<span class="bd-emoji">⭐️</span>-->
聊天
<!-- 很多人不晓得干什么。。。-->
</a >
<a class="navbar-item" href="https://bulma.io/expo/">
<!--<span class="bd-emoji">⭐️</span>-->
面经
</a >
<router-link class="navbar-item" to="/book">
<!--<span class="bd-emoji">❤️</span>-->
书籍
</router-link>
</div>
<div class="navbar-end">
<div class="login-before" style="padding-top: 5px;">
<!-- pc -->
<a class="navbar-item is-hidden-desktop-only" href="https://github.com/pkwenda/my-bbs" target="_blank">
<span class="icon" style="color: #333;">
<i class="fa fa-lg fa-github is-size-2"></i>
</span>
</a >
</div>
<div class="navbar-item is-hidden-mobile">
<div class="field has-addons" ><div class="control" ><input type="input" class="input" name="email" placeholder="搜寻一下" required="required" style="height: 36.4px;"><input type="hidden" name="redirect" id="name" value="/fr/#thanks"></div><div class="control" ><input type="submit" class="button is-warning" value="GO"></div></div>
</div>
<div class="navbar-item is-hidden-mobile">
<!--<span class="icon is-medium">-->
<i class="iconfont icon-tixing"></i>
<!--</span>-->
</div>
<div class="navbar-item has-dropdown is-hoverable">
<a class="is-hidden-mobile" target="_blank">
< img src="https://avatars2.githubusercontent.com/u/14212375?s=400&u=dc515636befebfda36501309d1cdc087ee31d500&v=4" class="header-avatar img-circle"
style="margin-top: 10px">
</a >
<div class="navbar-dropdown">
<a class="navbar-item" type="珍藏集">
写文章
</a >
<a class="navbar-item" type="徽章">
设置
</a >
<a class="navbar-item" type="排名">
退出
</a >
</div>
</div>
<div class="login-before">
<div class="navbar-item">
<div class="field is-grouped">
<p class="control">
<a class="button is-warning" v-show="!isLogin" >
<strong> 登录 </strong>
</a >
</p >
</div>
</div>
</div>
</div>
</div>
</nav>
</div>
</div>
</div>
</template>
<script>
export default {
name: "BeeHeader",
data() {
return {
popupShow: false,
isLogin: false,
user: {},
loading: false,
userInfo: {}};
},
created() {},
destroyed() {},
mounted() {},
methods: {}};
</script>
<style scoped>
.img-circle {
-webkit-border-radius: 50%;
-moz-border-radius: 50%;
border-radius: 50%;
}
</style>
什么款式能够写在 .vue 文件中
上文的比拟相熟的代码是让咱们的头像变圆的代码段
<style scoped>
.img-circle {
-webkit-border-radius: 50%;
-moz-border-radius: 50%;
border-radius: 50%;
}- 成果
这里我偷了个懒，刚好能够说一说，对于如此通用的款式，局限在 .vue 文件中，并且以 scoped 标示，宣判了它无奈复用的事实，任何模块想用这个款式，都须要复制一份，显然是不标准的，咱们通常还会建设通用的 css 文件进行治理，大型项目 css 治理标准将更加严格、标准的树级构造，具体就看 CTO 的想法了。
依据爱好抉择如何布局
按需引入
vim new-bee/src/renderer/components/HelloWorld.vue<template>
<div>
<Header></Header>
<!--<div class="container"> </div>-->
</div>
</template>
<script>
import Header from "@/components/layout/Header";
export default {
name: "NewBeeIndex",
components: {Header},
data() {return {};
},
destroyed() {},
mounted() {},
methods: {},
watch: {}};
</script>毛病是要一个一个引入，但长处是代码可读性高
全局引入
- App 主入口
vim new-bee/src/renderer/App.vue- 引入
<template>
<div id="app">
<Header></Header>
<!-- < img src="./assets/logo.png"> -->
<router-view/>
</div>
</template>
<script>
import Header from "@/components/layout/Header";
export default {
name: "App",
components: {Header}
};
</script>
<style>
</style>
- 查看成果
基于 webpack 爸爸的热部署，咱们无需刷新浏览器，webpack 偷偷用 ws 更新了咱们的内容。仿佛很完满，然而兴许大家发现了一个问题，咱们通过浏览器渲染进去的 dom 就能够看到：：
咱们在主 APP 入口引入了头部布局，App.vue 是紧临 <body> 元素的注释元素，而这个程序所有页面、子路由全部都是 App.vue 入口的子集，阐明全局引入布局会存在如下问题：
1、这个我的项目所有的我的项目都肯定会带上 Header 组件渲染的内容
2、而且会影响在下期《性能优化》中讲的 webpack 按需加载的性能。
当然能够再 Header 组件上书写逻辑条件, 过滤指定的路由，但会毁坏我的项目的易读性，难以保护
我集体是比拟举荐第一种：按需引入的形式。
持续布局
- 照猫画虎写好 Footer
vim new-bee/src/renderer/components/layout/Footer.vue<template>
<footer class="footer footer-light-medium" style="padding-bottom: 20px;padding-top: 20px;">
<div class="container">
<div class="columns">
<!-- Column -->
<div class="column is-4">
<div class="mb-20">
< img class="small-footer-logo" src="https://img.actd.tw/images/2018/11/17/" alt="">
<div class="footer-description pt-10">
new bee 是一个为开发者提供的专一于技术分享的开源社区, 所有源码均可在 github 上找到, 心愿对宽广开发者有所帮忙。</div>
</div>
<div>
<span class="moto"> 喜爱我的项目能够点赞反对 <a href="https://github.com/pkwenda/new-bee" target="_blank">
<span class="icon"><i class="fa fa-github"></i></span>
</a >.</span>
<div class="social-links mt-20">
</div>
</div>
</div>
<!-- Column -->
<div class="column is-6 is-offset-2">
<div class="columns">
<!-- Column -->
<div class="column">
<ul class="footer-column">
<li class="column-header">
Links
</li>
<li class="column-item"><a href="https://github.com/pkwenda/new-bee">Home</a ></li>
<li class="column-item"><a href="https://cssninja.io/themes">Blog</a ></li>
<li class="column-item"><a href="https://github.com/pkwenda/new-bee/wiki">Wiki</a ></li>
</ul>
</div>
<!-- Column -->
<div class="column">
<ul class="footer-column">
<li class="column-header">
Ressources
</li>
<li class="column-item"><a href="https://cssninja.io/help">Help center</a ></li>
<li class="column-item"><a href="https://cssninja.io/blog">Blog</a ></li>
<li class="column-item"><a href="https://cssninja.io/help/rules">Rules</a ></li>
</ul>
</div>
<!-- Column -->
<div class="column">
<ul class="footer-column">
<li class="column-header">
Terms
</li>
<li class="column-item"><a href="https://cssninja.io/help/terms/licenses/personal">Personal</a ></li>
<li class="column-item"><a href="https://cssninja.io/help/terms/licenses/developer">Developer</a ></li>
<li class="column-item"><a href="https://cssninja.io/help/terms/service">Terms of Service</a ></li>
</ul>
</div>
</div>
</div>
</div>
</div>
</footer>
</template>
<script>
export default {
name: "Footer",
data() {return {};
},
created() {},
destroyed() {},
mounted() {},
methods: {}};
</script>
别忘了在 HelloWorld 引入一下
- 看看成果
- 看起来成果还不错，接下来是 Content（注释）局部
vim new-bee/src/renderer/components/layout/Content.vue<template>
<div class="container" style="height:700px">
<h1 > 博客列表 </h1>
<article class="column is-3" v-for="blog in blogs" v-bind:key="blog">
<a class="bd-article-image is-bootstrap" >
<span class="bd-article-overlay"></span>
<span class="bd-article-icon">
<i class="fa fa-tag"></i>
</span>
<strong class="bd-star-icon" ><i class="fa fa-star"></i> <span style="font-size: 1rem"> {{blog.commendCount}}</span></strong>
<strong class="bd-article-info">
<span>
<time class="bd-article-date" datetime="2017-10-09T00:00:00+00:00">
{{blog.tag}}
</time>
<strong class="bd-article-title">
{{blog.title}}
</strong>
</span>
</strong>
</a>
</article>
</div>
</template>
<script>
let article = {tag: "java", title: "java", commendCount: 0};
export default {
name: "Footer",
data() {
return {
blogs: [
article,
article,
article,
article,
article,
article,
article,
article
]
};
},
created() {},
destroyed() {},
mounted() {},
methods: {}};
</script>
<style scoped>
.bd-article-image.is-bootstrap {background-color: #6f5499;}
.bd-article-image {
background-color: #00d1b2;
display: block;
height: 240px;
margin-left: auto;
margin-right: auto;
position: relative;
text-align: center;
}
.bd-star-icon {
font-size: 19.2px;
font-size: 1.2rem;
color: #0a0a0a;
opacity: 0.25;
bottom: 10px;
left: 30px;
position: absolute;
-webkit-box-align: center;
-ms-flex-align: center;
-webkit-align-items: center;
align-items: center;
display: -webkit-box;
display: -ms-flexbox;
display: -webkit-flex;
display: flex;
-webkit-box-pack: center;
-ms-flex-pack: center;
-webkit-justify-content: center;
justify-content: center;
}
.bd-article-icon,
.bd-article-info {
bottom: 0;
left: 0;
position: absolute;
right: 0;
top: 0;
-webkit-box-align: center;
-ms-flex-align: center;
align-items: center;
display: -webkit-box;
display: -ms-flexbox;
display: flex;
-webkit-box-pack: center;
-ms-flex-pack: center;
justify-content: center;
}
.bd-article-info {padding: 20px;}
a strong {color: currentColor;}
.bd-article-date {color: rgba(0, 0, 0, 0.5);
display: block;
}
.bd-article-title {
color: white;
display: block;
font-size: 1.8rem;
font-weight: 700;
line-height: 1.25;
padding: 0 20px;
}
.bd-article-icon {
color: #0a0a0a;
opacity: 0.25;
}
h1 {
text-align: center;
font-size: 30px;
}
.column.is-3,
.column.is-3-tablet {
-webkit-box-flex: 0;
-ms-flex: none;
flex: none;
width: 25%;
float: left;
}
</style>
- 看看成果
- HelloWorld.vue 代码看起来是这样的
还算看得过来，咱们持续参照图二
为 Content 制订 AD(广告) 组件。
vim new-bee/src/renderer/components/common/AD.vue
<template>
<div class="ad"><h1> 澳门 XX 赌场上线啦 </h1></div>
</template>
<script>
export default {
name: "AD",
data() {return {};
},
destroyed() {},
mounted() {},
methods: {},
watch: {}};
</script>
<style scoped>
.ad {
width: 150px;
height: 180px;
background-color: #ececec;
position: fixed;
right: 30px;
top: 80px;
}
</style>
- 别忘了在 Content.vue 引入一下
...
<AD></AD>
...
import AD from "@/components/common/AD";
export default {
name: "Content",
components: {AD},
...
}- 看下成果
- 比照一下咱们之前 sketch 画的草图
差不多实现了咱们初步的构思
Part 8 前端性能优化
本节橄榄
- 前端须要理解的 docker 基础知识
- 部署前端我的项目到本地 / 外网服务
- 前端我的项目的 gZip 优化
- 理解 CDN 的重要性
- webpack 按需加载
- 图片的相干优化
- 如何剖析我的项目依赖，不便针对性解决
- 如何减小 webpack 打包大小 / 速度
上线
咱们通常在本地开发，本地环境和线上也并非齐全一样，很多我的项目第一次上线简直都会遇到本地开发无奈复现的问题，可能是字体、款式的问题，也可能是 webpack 编译的问题、甚至可能是本地的奇葩环境。所以 本地完满运行 ≠ 线上完满运行，咱们须要 build 我的项目，模仿线上测试一下，看看是否能够完满运行，有问题能够不便及时作出调整。
筹备
为了防止本教程净化大家本地环境，举荐大家装置一个 docker，前期运维也会依据 docker 开展。
看到这个 Title：《筹备 docker》，没接触过的前端不要怂，装一个，敢于跨出第一步，不学习就是等死「点击这里理解 docker」
尽管 tomcat nginx apache jboss jetty 等等等等都能够作为 http 服务，本章以最常见的 nginx 开展讲述：
大白话介绍下 docker
docker 就是用更优雅的办法，做到了虚拟机的事件，并且做的更好，可编程治理集群。docker 启动容器，在容器外部运行你的环境，默认各个容器是相互隔离的，当然你能够通过 link network 关联容器，或者间接应用 docker-compose 编排，启动容器的前提是镜像，也相似与虚拟机的镜像，想跑容器，先得下载「pull」镜像。
应用 docker
兴许很多人没用过，没用过也不讲怎么装置了，本人去看官网吧中武官网、社区版下载、中国镜像减速，windows 的话可能要开启虚拟化，linux 举荐 ubuntu，有篇文章这样讲：为了性能请不要在 centos 中运行 Docker，查看翻译点这里)，几年前的文章了，当初怎么样有待讲究。
看下 images 状态
docker images
能够看到我曾经有一些镜像了「我曾经删除了 nginx」
dockerHub 拉 Nginx 镜像
docker pull registry.docker-cn.com/library/nginx:latest失常 docker pull nginx 即可，两头那段是中国镜像源
ok，咱们胜利 pull 下来了 Nginx 的镜像。默认存储的镜像名为：registry.docker-cn.com/library/nginx
打包
进入咱们上一章源码的目录，build 一下进行公布。
上一章源码在这里
npm run build
启动 docker 容器
docker run --name nginx -d -p 8888:80 -v /new-bee/dist:/usr/share/nginx/html registry.docker-cn.com/library/nginx
- 上调命令一些解释「不多讲，防止消化不良，本人探索」
| CMD | 解释 |
|---|---|
| -d | 守护过程运行 |
| -p | 端口映射 8888：80 docker80 端口映射到本机「宿主机」 |
| -v | 挂载宿主机的一个目录 本机「宿主机」: docker 容器 |
| —name | 为容器命名 |
测试一下
http://localhost:8888/#/
当然首次尝试 docker 你可能会有更多的疑难：
- 你怎么晓得须要将主目录挂载到：/usr/share/nginx/html ?
- 是否 / 怎么 查看 Nginx 日志 ?
- 容器内的 nginx 是否自定义配置 ?
- ……
这些小白问题本章简略讲讲，前面做主动运维的时候独自开展讲，能够关注我的博客
gZip
咱们能够通过 webpack 压缩脚本文件，上传到 http 服务器，浏览器浏览的时候，通过压缩的 HTTP 应答报文是由浏览器解压的，比起压缩，解压的速度是十分快的（只有数据失常，能够解压的话），所以不必放心浏览器用于解压的工夫会升高用户体验。事实上，浏览器解压耗费的这点工夫比起数据包因为网络拥挤而耽搁的工夫要少的多也可控的多。
在浏览器发给服务器的 HTTP 申请报文中，应用 Accept-Encoding 字段表明本人反对的压缩格局，即本人能够解压哪几种压缩报文（gzip、zlib 库提供的 deflate）。服务器回复客户端的 HTTP 应答报文中，应用 Content-Encoding 字段表明该应答报文应用哪种压缩形式。
gZip 攻破 webpack、nginx
像我这样屌丝的服务器个别都买 1M 的，大的资源文件 hold 不住，一个动辄 400K 的 vendar 文件这很蛋疼，不上 gZIp 很好受。
关上 network 察看一下:
它有 144K 这么大
咱们就以 webpack 打包的外围 vendor 为例，咱们发现，客户端向服务端申请了 gZIp 资源 Accept-Encoding: gzip, deflate，但惋惜服务端并没有给咱们现实中的 response - Content-Encoding: gzip 的响应, 咱们须要排查一下起因。
- 首先看看 webpack 到底打没打进去打进去 gZip 呢？看看他的目录有没有 js 的 .gz 文件。
很遗憾没有，只有一些压缩文件和用于定位的 map 文件，看来首先咱们的打包就呈现了问题。
大家还记得当初构建我的项目我发的这张图吗？
- package.json 我的项目形容文件
关上看看 build 命令执行了哪个脚本？
关上 build.js 看看执行了哪些内容，难道是 vue-cli 没有为咱们配置好 webpack gZip 相干的配置吗？
咱们发现没什么特地的，发现一个
const webpackConfig = require('./webpack.prod.conf')
的依赖，大略就是字面意思（webpack 生产配置）进去看看。
哦，咱们看到了，webpack 的确为咱们配置了 gZip 相干配置。
可是发现这个配置被这个判断包裹住了：
if (config.build.productionGzip) {}追踪上来
// Gzip off by default as many popular static hosts such as
// Surge or Netlify already gzip all static assets for you.
// Before setting to `true`, make sure to:
// npm install --save-dev compression-webpack-plugin
productionGzip: false,咱们的全副纳闷都被揭开了，开发者通过正文这样通知咱们他的理由，我简略翻译一下：
首先下载一下依赖：
vim package.json
"devDependencies": {"compression-webpack-plugin": "^1.1.12",}而后 productionGzip 改成 true
- 废话不多说打个包试试：
npm run build
胜利了，呈现了 .zg 文件压缩包，然而 gZip 是须要服务端的反对的，服务器通过客户端申请的 Accept-Encoding 首部开判断返回哪种格局的脚本文件，而后由浏览器解压，咱们拉下来的 nginx 镜像，nginx 是不会为咱们默认配置 gZIp 服务端压缩的，咱们去查看一下吧。
进入 docker 主机
docker exec -it nginx /bin/bash或者
docker exec -it nginx "bash"
| CMD | 解释 |
|---|---|
| exec | 进入 docker 容器 |
| -i | -i: 以交互模式运行容器，通常与 -t 同时应用； |
| -t | -t: 为容器重新分配一个伪输出终端，通常与 -i 同时应用； |
| -it | -it = -i -t |
| “bash”或 /bin/bash | /bin/bash 的作用是因为 docker 后盾必须运行一个过程，否则容器就会退出 |
进入 nginx 主机的第一件事
nginx 在哪？？？
Linux whereis 命令用于查找文件。
该指令会在特定目录中查找符合条件的文件。这些文件应属于原始代码、二进制文件，或是帮助文件。
该指令只能用于查找二进制文件、源代码文件和 man 手册页，个别文件的定位需应用 locate 命令。
语法
whereis [-bfmsu][-B < 目录 >...][-M < 目录 >...][-S < 目录 >...][文件...]- 查看 nginx 地位
root@e0017cab245f:/# whereis nginx
nginx: /usr/sbin/nginx /usr/lib/nginx /etc/nginx /usr/share/nginx
- 咱们在 /usr/share/nginx 找到了根目录 html/
- 咱们在 /etc/nginx/ 找到了 nginx 配置文件
ps 中间件这么多，谁记得住呢，记不住本人看看就行了不是吗?
- 查看一下 nginx 的配置
的确 gZip 真的没开启，被注掉了。
咱们关上 gZip 的正文，并且避免服务端对 css 偷懒，咱们一步到位加上几行经典配置。
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_comp_level 6;
gzip_types application/javascript text/plain application/x-javascript text/css application/xml text/javascript application/json;
gzip_vary on;
nginx 配置 代码在这里
如何批改 docker 外部的配置
就目前来看，你有两种办法能够抉择：
- 间接 exec 容器进行批改，减少上述 gZip 代码段。毛病：若想从新基于镜像构建容器容器内的配置会失落。（除非你 commit 镜像）
- 独立出配置文件，一劳永逸。
咱们基于第二点在 new-bee/ 目录 同级 创立了一个目录 nginx/ 创立一个同名的 nginx.conf 文件。
nginx 配置 代码在这里
- 先进行 nginx 容器
docker stop nginx- 删除 nginx 容器
docker rm nginx- 从新构建 nginx 容器
docker run --name nginx -d -p 8888:80 -v /new-bee/dist:/usr/share/nginx/html -v /nginx/nginx.conf:/etc/nginx/nginx.conf:ro registry.docker-cn.com/library/nginx- 看看成果
http://localhost:8888/#/为了防止浏览器加载方才的 304 缓存，革除下浏览器缓存或进行隐身模式
曾经见效了。
- 看看大小压缩到多少
只有 50K 左右，压缩了 2/3 的大小，这对于大型项目来说，节俭的不只是 100K，甚至是更多，webpack 或者说 gz 等压缩算法，会将所有的大量反复的片段独自标记，所以反复的越多，压缩的越多，这对于当初带宽比金子贵的云服务来说是非常重要的。
CDN
大家留神到，有些能用 CDN 的我抉择应用了 CDN，那么 CDN 对于线上服务来说到底有多重要呢?
原理
申请速度
废话先不说给大家上个比照图 测试地址
- 这是我的 论坛
能够看到仅有几个中央还算不错，其余中央都是一塌糊涂
- 这是淘宝
不用说了吧？不过还好，这部分咱们资金不足败了也很失常，但大家可能也大略晓得 CDN 的意义了，次要意义不是节俭开源我的项目服务器带宽，而是全国各个节点的访问速度问题，也就解释了：我部署的我的项目访问速度还不错，你这里怎么这么慢，你网不好吧？CDN 来通知你答案。
cookie
咱们还是拿实战的 bbs 论坛 举例子吧，查看网络状态：
应用 CDN 的几点劣势
- 拜访快
- 服务端压力小
- webpack 打包小且快（上面讲）
客户端的 cookie 是绑定服务端 域名 的, 看上图，咱们须要 XHR 申请携带 cookie 拜访服务端获取对应权限，但试想一下：每一个 js、img、甚至是 css 都携带垃圾的 cookie，在大用户量下，服务端接受着不应该属于他的苦楚，这样的耗费是特地应该防止的，咱们能够轻易翻一翻任何一个成熟的网站，都会发现存在本人的 CDN 服务，这样既优化了中国不同地区的访问速度，同时也大大减小了服务端的开销。
节俭 webpack 打包大小 / 速度
很长时间前经验过公司前端 webpack 编译特地慢的问题，dev 模式下咱们能够注掉开发范畴外的 路由，然而 build 公布的时候仿佛没法解决，应用了 Happypack 多线程打包还是不如人意，查阅材料读到了 这篇文章
咱们能够把可能 externals 调的排除掉，而后应用 webpack 的 webpack.DllPlugin 生成依赖库（这点很重要），大大减少便以速度，DllPlugin 实质上的做法和咱们手动拆散这些第三方库是一样的，然而对于包极多的利用来说，自动化显著放慢了生产效率。
如何剖析我的项目依赖
webpack-bundle-analyzer
其实很多人都晓得，可能刚入坑的同学不太理解，不论是 npm maven 都有本人一套以来剖析工具，当然也都来源于第三方，这里为大家介绍 npm 的以来剖析工具：webpack-bundle-analyzer，他会在浏览器生成一个报表，直观的展现哪里大，哪里须要优化，以及预测 gZip 的大小，还是以 实战我的项目为例：
依照官网指引的配置，下载依赖，package.json 文件指定下 build 的脚本：
"analyz": "NODE_ENV=production npm_config_report=true npm run buildProd",运行一下：
npm run analyz
成果：
剖析：
发现了问题，static/ 动态文件下 hightlight 文件比拟大，有钱能够思考下 CDN，node_modules/ 下 element-ui 饿了么组件比拟大，（我比拟懒，全局导入的，能够用哪个引入哪个防止全局打包问题）能够优化，而后无聊的同学没事儿点点玩玩吧。
webpack 按需加载：所有皆模块
当打包构建利用时，Javascript 包会变得十分大，影响页面加载。如果咱们能把不同路由对应的组件宰割成不同的代码块，而后当路由被拜访的时候才加载对应组件，这样就更加高效了。Webpack 的代码宰割性能，实现路由组件的懒加载.
官网具体阐明
官网说的挺具体了，这里就偷个懒不上代码了，给大家提供一种经典解决形式，咱们不放在组件上，间接对路由进行拆分，具体能够看 实战我的项目路由 的路由拆分
会发现很多这种正文：
const Blog = () => import(/* webpackChunkName: "blog" */ '@/container/blog/Blog')那么相似：
/* webpackChunkName: "blog" */不是白写的，他是配合 webpack 对我的项目各路由拆分的，咱们能够看看 理论我的项目加载状况：
这个 blog.hash.js
不是咱们写的，是 webpack 进行宰割的，这样相似 vue 这样的单页面架构，不会加载某模块总是加载全副脚本，大大晋升加载速度。
图片解决
原本不想讲的，简略说说吧，罕用的也就那几种 svg、base64、或应用 fastdfs 组件相似 CDN 的服务。
base64
简略来讲 base64 会缩小你的 http 申请数量，要晓得 XHR 可不是省油的灯，他会带来额定的解决申请和解决响应损耗，以表情为例，动辄几十个表情 http 申请仿佛太智障了一些，通常采纳 base64 解决，缩小了 http 申请数量，然而增大了图片自身的体积，如果你用了 webpack 且你的表情在本地，那么 webpack 能够帮你主动进行 base64 编码哦。
压缩图片
用户上传的图片能够通过压缩图片大小或品质缩小带宽哦，通常应用 GM 对用户上传的有必要大锁的图片 压缩成不同大小的，依据业务加载，比方头像，默认必定不会申请原始图片，今日头条的注释，应用流量的状况下也会默认加载小图，这些都不是客户端能做到的，须要服务端压缩。
结语
当然这些常识万里长征的第一步，当前的优化之路茫茫多，能大略想起来的比方：Lazy-Load（优化首屏体验）、PWA（构建 web APP）、服务端渲染（为了 SEO）、骨架屏（晋升用户体验），后端和服务端文章还没写，1.0 版本就放这些吧，期待第二版填坑，下篇开始后端。
SO – 致力吧!
博客归档地址：https://github.com/pkwenda/blog
博客实例地址：https://github.com/pkwenda/new-bee