Swan
Swan
### 问题 在阅读vue3的源码过程中，遇到了很多有意思的代码，比如以下这一段： ```js const arrayInstrumentations: Record = {} ;['includes', 'indexOf', 'lastIndexOf'].forEach(key => { arrayInstrumentations[key] = function(...args: any[]): any { const arr = toRaw(this) as any for (let i =...
# reactive ### makeMap 先看个工具函数： ```js // Make a map and return a function for checking if a key // is in that map. // // IMPORTANT: all calls of...
# ref ref类型是用来做基本类型包装的，一个普通的对象可以通过Proxy来做劫持，但是基本类型行不通，vue3的做法是直接把基本类型包装在一个object的`.value`中，同时直接劫持这个object.value的getter和setter来实现响应式。 ### isRef ```js const isRefSymbol = Symbol() export interface Ref { // This field is necessary to allow TS to differentiate a Ref from a plain //...
# HtmlWebpackPlugin使用模板引擎进行变量动态注入 HtmlWebpackPlugin是一个用来生成html页面的webpack插件，目前最新已经到了4.0.0-alpha.2。 说起来这个版本的tapable生命周期有些问题（见[https://github.com/jantimon/html-webpack-plugin/issues/1049](https://github.com/jantimon/html-webpack-plugin/issues/1049)），不过不要在意这些细节，最近工作中需要对多页应用做一些动态注入变量的操作，在此总结一下。 ## 背景 多页面应用又称MPA，在构建编译的时候比起单页应用来说更为复杂。 对于生成html来说，不同的页面html，90%的内容是基本一致的，但是有10%的内容，每个页面需要有自己的区别。  比如上图中的标题👆🏻。 ## 问题 当我们确认，MPA的模板统一为一个`base.html`后，问题就来了： **如何设计业务开发者的操作路径or配置**，可以**提高开发效率**又拥有**足够的扩展性**呢？ ## 业务开发者的配置 按照约定大于配置的思想，我们要在多页面入口配置中，混入可扩展的配置项： ```js /** * @typedef {Object}pageInfo * @property {string} path * @property {string} title...
可以针对正负号，整数及小数做匹配，研究了四分之三个上午，猝不及防在实验室漏水成水帘洞之际赶紧记录~ ## 只有正整数 | 输入 | 期待输出 | | --- | --- | | 123456 | 123，456 | | 123 | 123 | | 1234 | 1，234 | 只有正整数的时候那真是轻松加愉快，一行正则就可以搞定。 参考文章中匹配的是逗号应该在的位置，我自己当时是想匹配逗号左边的那个数字进行替换，两种方法都写出来：...
# 基于webpack4[.3+]构建可预测的持久化缓存方案 本文针对的是`immutable content+long max-age`类型的web缓存。 校验缓存及service worker的处理方案后续有时间再更新。 web缓存的好处不用多说，自从webpack一桶江湖后，如何做Predictable long term caching with Webpack让配置工程师们头疼不已。 webpack4.3前，有相当多的文章介绍如何处理（见参考），这里想做些更到位的探索。 ## 问题 **当业务开发完成，准备上线时，问题就来了**🤡： 1. 如何保证不同内容的资源拥有唯一的标识（hash值）？ 2. 修改了业务代码，重新打包，会不会导致所有资源的标识值都变动？ 3. 如果想稳定hash值，如何确保将变动的文件名降到最低？ 4. css/wasm等资源的变动，是否会影响chunk的哈希值？ 5. 业务中引用的顺序改变，是否会改变chunk的哈希值？是否应该？ 6. dynamic import的文件是否支持良好？...
# 真机调试教程 ## 背景 1. 百度端能力需要在baidu.com域下生效 2. 端能力调用调试时必须在真机上进行，但是没有console控制台和network查看网络请求 3. 端webview很多情况下和chrome表现不一致 4. 端上会做很多骚操作，chrome下调试没法感知 5. 因为没有可靠的调试环境，多人协作时，fe频繁推送代码到qa环境进行验证，甚至alert输出，导致qa环境不可测试、开发效率低、多人代码覆盖冲突。 6. 真机的DOM/CSS无法查看 ## 使用whistle解决上述问题 1. 配合weinre在mac上查看/修改真机的DOM树 2. 网络请求代理至mac本地 3. 真机的console输出代理至mac本地 **github地址和文档**：[https://github.com/avwo/whistle](https://github.com/avwo/whistle) ## 准备工作 #### 安装 1....
# 从网络请求入手优化产品体验 ## 以用户为中心 对于web产品来说，加载时间和快速响应是两个影响体验的重要指标。 加载时间很好理解，**1s打开的页面肯定会比3s打开的页面体验好**。 那么响应时间呢？ 根据**GOOGLE的RAIL模型**量化描述： |操作响应---延迟时间 | 用户反应 | | --- | --- | |0 - 16 毫秒|人们特别擅长跟踪运动，如果动画不流畅，他们就会对运动心生反感。 用户可以感知每秒渲染 60 帧的平滑动画转场。也就是每帧 16 毫秒（包括浏览器将新帧绘制到屏幕上所需的时间，留给应用大约 10 毫秒的时间来生成一帧。| | 0...
# 响应式图片方案 ## 现状 对于图片的处理，我们**目前一律采用3倍图尺寸的原图格式（.jpg/.png等）**。 然而，移动端设备千差万别，这样的原图在很大程度上都是一种加载资源的浪费。 ## 从精细化运营出发 从精细化运营的角度思考，我们要关注以下几个问题： - devicePixelRatio： 设备是iphone 8这样的2倍图手机，还是iphone 8 plus等3倍图设备？2倍图手机加载三倍图片，这是一种不必要的流量消耗，同时也降低了性能。 - 是否支持webp：  安卓机器支持**webp图片格式，相比原图，可以降低30-80%左右的图片体积，观感上没有区别**，这样的收益是不可忽略的；然而苹果手机完全不支持。 - 图片资源的hash值：  图片的hash值是根据图片内容尺寸生成的，对于长缓存的资源，这是一种保护，然而也意味着hash值有可能频繁变动，如果需要在运行时做些图片的处理，处理hash值会很头疼。 - 压缩图片：  压缩是使用tinypng好，还是其他服务好？免费不？一次上传几张？解压再copy回来？ - 对首屏图片资源进行预加载： 现代mvvm框架，只有当生成的DOM元素进入renderTree后，匹配到的css中的图片资源才会开始加载。然而**框架下载、初始化、解析模板、生成元素及渲染页面是有时间成本的**，这个时间大概在100-1000ms不等。...
# 告别head标签中加载js sdk进行白屏时间打点吧~ ## 背景 很久很久以前，我们监控线上业务的白屏时间，是通过在head标签中加载一段js sdk，然后打点记录白屏时间的。  那个时候没有更现代的统计API，而且body下面就是html的描述，所以这样做确实可以统计出白屏时间。 ## 问题 #### sdk的引入本身影响了白屏时间  可以看到，在弱网3G情况下，sdk的下载和执行就要600ms，公网的sdk通常都不会设置强缓存，这代表每次访问都会让白屏时间拖慢600ms。 测出来的时间，自然也是不准的。 #### 前端渲染的场景下，不准 ```html ... ... ``` 相信这段html大家都不陌生了，因为前端渲染基本要依赖js的下载和执行，一个前端框架的解析和执行就要几十毫秒至几百毫秒不等，在head中打点并不是真正的白屏时间了。 #### 现代环境，没有意义 是的，在现代场景下，可以使用performance.timing统计所有你需要的时间。  不但够精准，**而且不会影响首屏性能。** ## 结论...