Lindz
Thanks to provide the nice plugin, but I got a problem: In my project, I have multiple entry(many pages) and some common chunks. How could I do to let each...
[原文地址](https://github.com/happylindz/blog/issues/17) 衡量网站的性能的指标有很多，其中有项重要的指标就是网站的首屏时间，为此前端工程师们都是绞尽脑汁想尽办法进行优化自己的应用，诸如像服务端渲染，懒加载，CDN 加速，ServiceWorker 等等方法，今天介绍的 preload/prefetch 是一种简单，但却事半功倍的优化手段。 ## 基本用法 在网络请求中，我们在使用到某些资源比如：图片，JS，CSS 等等，在执行之前总需要等待资源的下载，如果我们能做到预先加载资源，那在资源执行的时候就不必等待网络的开销，这时候就轮到 preload 大显身手的时候了。 ### preload 提前加载 preload 顾名思义就是一种预加载的方式，它通过声明向浏览器声明一个需要提交加载的资源，当资源真正被使用的时候立即执行，就无需等待网络的消耗。 它可以通过 Link 标签进行创建： ```html const link = document.createElement('link'); link.rel = 'preload'; link.as =...
[原文地址](https://github.com/happylindz/blog/issues/5) # 前端代码异常监控实战 ## 前言 之前在对公司的前端代码脚本错误进行排查，试图降低 JS Error 的错误量，结合自己之前的经验对这方面内容进行了实践并总结，下面就此谈谈我对前端代码异常监控的一些见解。 本文大致围绕下面几点展开讨论： 1. JS 处理异常的方式 2. 上报方式 3. 异常监控上报常见问题 ## JS 异常处理 对于 Javascript 而言，我们面对的仅仅只是异常，异常的出现不会直接导致 JS 引擎崩溃，最多只会使当前执行的任务终止。 1. 当前代码块将作为一个任务压入任务队列中，JS 线程会不断地从任务队列中提取任务执行。 2. 当任务执行过程中出现异常，且异常没有捕获处理，则会一直沿着调用栈一层层向外抛出，最终终止当前任务的执行。...
[原文地址](https://github.com/happylindz/blog/issues/16) 在英文或者中文的网站，我们习惯的阅读方式都是从左往右的，所以你在访问国内外的网站的时候会发现，不管是文字还是布局，都是从左往右进行排版，而我们也熟悉和适应了这种阅读习惯，但是在中东地区，有很多国家，诸如像阿拉伯语、希伯来语，他们的阅读习惯却是从右到左的，恰好跟我们是相反的，我也查阅了大量阿拉伯语的网站的设计，感兴趣也可以点击下面的网站看看： * [http://wam.ae/ar](http://wam.ae/ar) * [https://www.emaratalyoum.com/](https://www.emaratalyoum.com/) 通过上面的网站，可以很直观地看出像阿拉伯语，典型 RTL 布局网站的特点： 1. 文字都是右对齐，并且是从右往左阅读的 2. 排版都是从右到左的，在一个产品列表中，右边第一个商品是第一个 3. 箭头代表的意义刚好相反，比如在轮播图中，向左箭头代表下一帧，而向右箭头则代表查看上一张图片 知道了 RTL 布局的特点，我们在使用场景上需要考虑： 1. 如何以较低的成本，可维护，兼容地改造线上已有的场景支持 RTL 布局网站 2. 对于未来新的场景，怎么样在编码的环节可以快速支持 LTR、RTL 布局特点的网站 所以本文探究的是**在假定语言文案，图片等信息正确的情况下，如何使用一套代码，不仅可以支持像英文，中文等 LTR 布局的网站，也可以支持像阿拉伯，希伯来语等 RTL...
[原文地址](https://github.com/happylindz/blog/issues/19) ## 前言 在 React 的世界中，有容器组件和 UI 组件之分，在 React Hooks 出现之前，UI 组件我们可以使用函数，无状态组件来展示 UI，而对于容器组件，函数组件就显得无能为力，我们依赖于类组件来获取数据，处理数据，并向下传递参数给 UI 组件进行渲染。在我看来，使用 React Hooks 相比于从前的类组件有以下几点好处： 1. 代码可读性更强，原本同一块功能的代码逻辑被拆分在了不同的生命周期函数中，容易使开发者不利于维护和迭代，通过 React Hooks 可以将功能代码聚合，方便阅读维护 2. 组件树层级变浅，在原本的代码中，我们经常使用 HOC/render props 等方式来复用组件的状态，增强功能等，无疑增加了组件树层数及渲染，而在 React Hooks...
[原文地址](https://github.com/happylindz/blog/issues/12) # 纯 CSS 实现多行文字截断 ## 前言 最近在做响应式系统设计的时候遇到需要对标题进行多行文字截取的效果，如下图：  看似十分简单的标题截断效果，但是竟然没有一个统一 CSS 属性实现标准，需要用到一些奇淫妙计来实现，一般来说，在做这样文字截断效果时我们更多是希望： 1. 兼容性好，对各大主流浏览器有好的支持 2. 响应式截断，根据不同宽度做出调整 3. 文本超出范围才显示省略号，否则不显示省略号 4. 省略号位置显示刚好 基于上述的准则，下面我就讲介绍各种技巧实现截断效果，并根据上述的评判标准得出最优解。(**代码我都传到 jsfiddle 平台，可点击 demo 地址查看**) ## 单行文本截断 text-overflow 文本溢出我们经常用到的应该就是 text-overflow:...
[原文地址](https://github.com/happylindz/blog/issues/3) # 跨域，你需要知道的全在这里 这篇文章是之前写的，我重新整理了下，阅读本文前，希望你有一定的 JS/Node 基础，这里不另外介绍如何使用 Ajax 做异步请求，如果不了解，可以先看： [Ajax知识体系大梳理](http://louiszhai.github.io/2016/11/02/ajax/) 最近在面试的时候常被问到如何解决跨域的问题，看了网上的一些文章后，许多文章并没有介绍清楚，经常使读者(我)感到困惑，所以今天我整理一下常用的跨域技巧，写这篇关于跨域的文章目的在于： 1. 介绍常见的跨域的解决方案以及其优缺点 2. 模拟实际的跨域场景，在每种方案后给出一个简单的实例，能够让读者和我一起敲代码，直观地理解这些跨域技巧 如果觉得本文有帮助，可以点 star 鼓励下，本文所有代码都可以从 github 仓库下载，读者可以按照下述打开: ```bash git clone https://github.com/happylindz/blog.git cd blog/code/crossOrigin/ yarn ``` 建议你 clone 下来，方便你阅读代码，跟我一起测试。...
## 前言 我们在使用 webpack 打包构建 moment 库的时候，moment 默认会将所有语言包全部引入，这样就会导致打包后的 JS 体积增大，通过 ```webpack-bundle-analyzer``` 分析工具可以看到，如果将所有的 moment 语言包引入的话，所占 JS 体积是相当庞大的。gzip 之后也要占据 65kb 的文件大小。  所以如果应用没有国际化背景的需求下，我们一般都会通过 ```webpack.IgnorePlugin(/^\.\/locale$/, /moment$/)``` 将所有语言包进行剔除，不进行打包，这样打包后的 moment 体积就只有 16kb。  正常的业务诉求到这里结束了，但是我们阿里巴巴国际站需要支持 14...
[原文地址](https://github.com/happylindz/blog/issues/2) # Redux 异步流最佳实践 阅读本文之前，希望你对 Redux 有个清晰的认知，如果不熟悉的话可以看这篇文章：[揭秘 React 状态管理](https://github.com/happylindz/react-state-management-tutorial) 如果觉得本文有帮助，可以点 star 鼓励下，本文所有代码都可以从 github 仓库下载，读者可以按照下述打开: ``` git clone https://github.com/happylindz/blog.git cd blog/code/asynchronousAction/ cd xxx/ yarn yarn start ``` 我们知道，在 Redux 的世界中，Redux action...
[原文地址](https://github.com/happylindz/blog/issues/7) # webpack 持久化缓存实践 ## 前言 最近在看 webpack 如何做持久化缓存的内容，发现其中还是有一些坑点的，正好有时间就将它们整理总结一下，读完本文你大致能够明白： 1. 什么是持久化缓存，为什么做持久化缓存? 2. webpack 如何做持久化缓存？ 3. webpack 做缓存的一些注意点。 ## 持久化缓存 首先我们需要去解释一下，什么是持久化缓存，在现在前后端分离的应用大行其道的背景下，前端 html，css，js 往往是以一种静态资源文件的形式存在于服务器，通过接口来获取数据来展示动态内容。这就涉及到公司如何去部署前端代码的问题，所以就涉及到一个更新部署的问题，是先部署页面，还是先部署资源？ 1. 先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本资源当做新版本缓存起来，其结果就是：用户访问到一个样式错乱的页面，除非手动去刷新，否则在资源缓存过期之前，页面会一直处于错乱的状态。 2. 先部署资源，再部署页面：在部署时间间隔内，有旧版本的资源本地缓存的用户访问网站，由于请求的页面是旧版本，资源引用没有改变，浏览器将直接使用本地缓存，这样属于正常情况，但没有本地缓存或者缓存过期的用户在访问网站的时候，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误。 所以我们需要一种部署策略来保证在更新我们线上的代码的时候，线上用户也能平滑地过渡并且正确打开我们的网站。 推荐先看这个回答：[大公司里怎样开发和部署前端代码？](https://www.zhihu.com/question/20790576/answer/32602154) 当你读完上面的回答，大致就会明白，现在比较成熟的持久化缓存方案就是在静态资源的名字后面加 hash...