IceHoney IceHoney
IceHoney

前端部署之CDN的那些事情

frontend

现在的前端开发主流是 PWA，简而言之就是像 App 一样使用。基于 PWA 技术可以离线访问，并且可以添加程序到菜单里。离线技术使用的是比较成熟的 Service Workers。但是配合 CDN 就有很多不得不注意的事情。

# CDN 部署静态资源

现代化前端开发主要是把 CSS，JS，图片等静态资源放在 CDN 上有效提高载入速度。把静态 HTML 文件放在服务器上，有利于更新网站最新状态，例如进入维护状态，直接把静态 HTML 文件替换为维护页面即可。

# 同源策略问题

正常情况下，资源文件和主网站不在同一个域名下，例如主网站是icehoney.me，资源网站是static.icehoney.me。当然了，资源文件使用 GET 方法浏览器自动载入，没有任何问题。但是注册 Service Worker 的 JS 文件是不能放在 CDN 上的，因为这是官方的规定。个人理解是出于安全因素的考虑。所以我们在主服务器上不仅要放静态的 HTML 文件，还要放一个 serive-worker.js 文件。

# SVG symbol 的使用问题

现在前端的开发针对很多小图标，都是采用 SVG 的方式来引用。其中 SVG symbol 特别好用，可以在页面里嵌入一个 inline 的 SVG，然后在其他对方使用<use>标签来引用。但是对于放在 CDN 上的 SVG 文件，不能直接使用下面的形式：

<use xlink:href="https://static.icehoney.me/icon.svg#china" />
1

如果引用 CDN 的 SVG 浏览器会报错，解决方案是使用svg-inline-loader，手动在 HTML 里面注入 SVG 文件。document.body.insertAdjacentHTML 方法可以注入 inline 的 SVG。

# Workbox 配置

首先，PWA 项目的路由都是由前端来处理，所以我们需要使用navigateFallback保证不管导航到哪个路由都能映射到缓存的 HTML 文件。然后是使用runtimeCaching配置缓存服务器请求。

# 总结

由于 Service Workers 的导入使得 CDN 部署变得有些麻烦，不过这些问题好在都能找到解决方案。还有一点是 Chrome 的 Network 面板里的 offline 模式不能测试 Service Workers 的离线。需要自己手动拔网线才能测试。

# 引用

Is it possible to serve service workers from CDN/remote origin? (opens new window)

Workbox webpack Plugins (opens new window)

前端开发的技术栈

frontend

我发现自己博客没次开头都是在说近况和废话。这次也不例外。哈哈哈，工作也算顺畅，顺便总结下最近的前端开发的技术栈来回顾下这半年学到的知识。

# HTML 开发

对于大型项目，直接书写 HTML 代码是一个非常繁琐和头疼的事情，因为 HTML 需要闭合，每次找匹配的 HTML 标签都要非常花功夫。所以现在的开发都是使用预处理器来书写代码，例如主流的Pug (opens new window)，通过缩进来控制元素的嵌套，还支持多种语法。非常适合大型项目的开发，再也不用担心修改代码的时候出现 HTML 元素标签没有闭合的情况发生了。而且还规避了一些语法错误，例如在p标签里嵌入block元素是非法的。如果强行嵌入的话，你会发现生成的 HTML 代码是错误的。

# CSS 开发

CSS 开发更多的需要是良好的模块化功能和合理的作用域。这时候也需要通过预处理器来进行操作，推荐使用SCSS (opens new window)。这里很多人对sass和scss之间的区别有疑问。简单的来说，SCSS的格式更接近 CSS，所以比较容易上手。但是SASS是通过缩进来书写的，对新手不太友好。所以建议大家使用SCSS来书写模块化代码。

# JavaScript 开发

现在主流的浏览器支持的 JavaScript 版本是 es5。但是众所周知，JavaScript(es5)有很多陷阱和缺点，例如this指针问题和异步处理等等。基于原型连的继承对于面向对象开发者来说也很不友好。所以推荐使用es6 (opens new window)来书写代码。可以使用基于class的继承，和解决this指针问题。而且还能使用import进行模块化开发。虽然只是语法糖，但也提升了开发效率。

# 自动化构建工具

我们使用了预处理器来书写代码，并使用新版本的es6语法。但是目前浏览器并不支持直接解析这些内容。所以我们需要构建化工具来处理从 Pug 生成 HTML，从 SCSS 生成 CSS，把 es6 语法的 JavaScript 转换成 es5 语法。对于 SPA 网站推荐使用webpack，而对于普通网站的构建推荐使用Gulp。这里区别开的原因是，webpack必须指定入口文件，但是Gulp只需要指定需要处理的文件或文件夹就可以了，支持通配符匹配。对于多页面的传统网站来说非常便利。

# 浏览器兼容处理

这是每个前端工程师最头疼的地方了，因为每个浏览器支持程度都不一样。在使用比较新的 API 记得去Can I use (opens new window)查看下各个浏览器的支持情况，如果实在是需要这个功能的话，那就只能去寻找polyfill了。

参考：

Why p tag can't contain div tag (opens new window)