也不知道为什么，每一次工作变动，所接手的第一个项目，都和项目迁移有关。这次也不例外，在 5 月初入职乐天之后，处理完杂七杂八的事情，第一个接手的项目是将一个大概有 5 年开发周期的 nuxt 2 前端项目，迁移到 nuxt 3 版本。

webp 是 google 提倡的一种新的 image 格式，意在为 web 提供体积更小的图片格式。通常情况下，无损压缩可以减小 25%-35% 的体积（有例外情况，反而会增大体积，但是是因为转换图片格式不兼容引起的），有损压缩最大可以节省大约 75%-90% 的体积。

前期准备 一个使用 CRA 创建的新项目或者旧项目 了解 publicPath 是什么 了解 single-spa 中关于微前端应用的概念（及 qiankun 中 html-entry  的概念） 解决如何覆盖 CRA 配置的问题 通常情况下，覆盖 CRA 配置的解决方案有两种： 直接 npm run eject  使用 react-app-rewired 或者 rescripts 等第三方工具 这里使用第...

因为 JSON 语法比 Javascript 的语法更简单，因此解析 JSON 比解析 Javascript 更高效。当一个 web app 需要加载在首次加载时，解析一个非常复杂的、大型的、符合 JSON 规范的对象字面量配置对象时（比如配置 redux 的 store），我们可以根据这一点来提升首屏加载性能。

距 typescript 3.7 正式发布已经有一段时间了，这段时间正在对手上的项目进行 typescript 的迁移工作，所以会特别留意每一次的 release。

在分享 vue-next 各个子模块的实现之前，我觉的有必要比较全面的整理下 vue-next 中提出的函数式 api，了解这些的话，无论是对于源码的阅读，还是当正式版发布时开始学习，应该都会有起到一定的辅助作用。

最近又抽时间把 vue-next/runtime-core 的源码陆陆续续地看完了，期间整理了很多笔记，但都是碎片化的。本来是想整理一下，写成一篇文章分享出来的，但是感觉最终的成果物只能是一篇篇幅巨长的解析文，就算我一行一行的把源码加上注释，其阅读体验也会很差，因为每个人读代码的习惯不同，思路不同。正所谓抛砖引玉，所以...

最新 vue-next 的源码发布了，虽然是 pre-alpha 版本，但这时候其实是阅读源码的比较好的时机。在 vue 中，比较重要的东西当然要数它的响应式系统，在之前的版本中，已经有若干篇文章对它的响应式原理和实现进行了介绍，这里就不赘述了。在 vue-next 中，其实现原理和之前还是相同的，即通过观察者模式和数据劫持，只不...

写这篇文章的原因是因为，这几天在看 core-js 的源码，然后发现了 queueMicrotask 的实现。由于之前做的项目，对于微任务的执行需求，一般是使用 asap 这个库来完成的，如果没有使用这个库的话，简易版本可以通过 Promise.resolve() 来代替，并没有接触过这个 api，所以就想着抽时间研究一下。

写这篇文章的动机，完全是因为在每日逛 SF 的过程中，发现了一起分享你的故事这个活动，出于标题处小姐姐爆表的颜值让我有了恋爱的感觉以及对于奖品中 T-shift 的渴望，我无情地抛下了手头的工作（明天还给做 hotfix 发布），写下了这篇文章。

使用 react hook 来做公司的新项目有一段时间了，大大小小的坑踩了不少。由于是公司项目，因此必须要编写单元测试来确保业务逻辑的正确性以及重构时代码的可维护性与稳定性，之前的项目使用的是 react@15.x 的版本，使用 enzyme 配合 jest 来做单元测试毫无压力，但新项目使用的是 react@16.8 ，编写单元测试的时候，遇...

这个媒体查询属性的作用是，当用户在操作系统中设置了 reduced-motion 的选项时，能够根据其值声明不同的 css 样式，因为有的人可能喜欢炫酷的特效，有的人可能更倾向于内容（比如我），而有的人甚至因为生理问题无法接受这些特效。

JSON.stringfy()是将一个 JavaScript 对象转化为 JSON 格式字符串的标准方式。许多 JavaScript 框架在其内部，都会使用 JSON.stringify()：Express的 res.json()、Axios的 post，以及webpack stats，它们都调用了 JSON.stringify() 方法，并包含错误案例。

最近没怎么写新的东西，一是因为一直在准备换新的工作，所以一直在准备面试，二是因为过年，心静不下来，所以也无法输出或者翻译一些文章，三是由于手头还有一些遗留工作需要完成和交接，比较忙。

2018 马上就过去了，今年对于我来说是很特别的一年，因为去年的现在，我曾经十分迷茫，因为工作这几年，写了很多代码，参与了很多项目，但总有一种碌碌无为的感觉，而且似乎离成为一名合格的全栈工程师越来越远了。因此，去年给自己定下的目标就是，在新的一年中，一定要远离自己的舒适区，开拓自己的视野，尽可能的 for...

之所以翻译这篇文章，是因为自从成为一名前端码农之后，调接口这件事情就成为了家常便饭，并且，还伴随着无数的争论与无奈。编写友好的 restful api 不论对于你的同事，还是将来作为第三方服务调用接口的用户来说，都显得至关重要。关于 restful api 本身以及设计原则，我陆陆续续也看过很多的文章和书籍，在读过原文后...

到此为止，我们的 toggle 组件已经足够强大以及好用了，因此这篇文章不会再为它增加新的特性。如果你是从第一篇文章一直读到这里的读者，你一定会发现，整篇文章中，我几乎没有对 toggle-on 和 toggle-off 做出任何更改和重构，因此这篇文章着重来重构一下它们。

在第七篇文章中，我们对 toggle 组件进行了重构，使父组件能够传入开关状态的初始值，同时还可以传入自定义的状态重置逻辑。虽然父组件拥有了改变 toggle 组件内部状态的途径，但是如果进一步思考的话，父组件并没有绝对的控制权。在一些业务场景，我们期望父组件对于子组件的状态，拥有绝对的控制权。

到目前为止，仅从 toggle 组件自身的角度来看，它已经可以满足大多数的业务场景了。但我们会发现一个问题，就是当前 toggle 组件的状态对于调用者来说，完全是黑盒状态，即调用者无法初始化，也无法更改组件的开关状态，这在一些场景无法满足需求。

之前的五篇文章中，switch 组件一直是被视为内部组件存在的，细心的读者应该会发现，这个组件除了帮我们提供开关的交互以外，还会根据当前 toggle 的开关状态，为 button 元素增加 aria-expanded 属性，以 aira 开头的属性叫作内容增强属性，它用于描述当前元素的某种特殊状态，帮助残障人士更好地浏览网站内容。

在之前的文章中，详细阐述了子组件获取父组件所提供属性及方法的一些解决方案，如果我们想在父组件之中访问子组件的一些方法和属性怎么办呢？设想以下一个场景：

在第三篇文章中，我们使用 mixin 来抽离了注入 toggle 依赖项的公共逻辑。在 react 中，类似的需求是通过 HOC 的方式来解决的，但是仔细想想的话，react 在早些的版本也是支持 mixin 特性的，只不过后来将它标注为了 deprecated。

之前一篇文章中，我们虽然将 toggle 组件划分为了 toggle-button、toggle-on 和 toggle-off 三个子组件，且一切运行良好，但是这里面其实是存在一些问题的：

熟悉 vue 的童鞋可能马上会想到不同的解决方案，比如使用 slot 并配合 v-if，我们这里采用另外一种方法，利用 vue 提供的 provide/inject 属性按照复合组件的思想来实现。

去年，曾经阅读过一系列关于高级 react 组件模式的文章，今年上半年，又抽空陆陆续续地翻译了一系列关于高级 angular 组件模式的文章，碰巧最近接手了一个公司项目，前端这块的技术栈是 vue。我对于 vue 本身还是比较熟悉的，不过大多都是一些很简单的个人项目，在构建相对比较复杂的应用中缺乏实践经验，就想着也搜搜类...

最近抽空参加了几场大厂的面试，突然发现一个现象，就是不论面试偏服务端的职位还是偏客户端的职位，不论面试的 5 年以上的高级职位，还是 3 年左右的中级职位，面试官开头所问问题必然是关于 HTTP 的。

因为父组件会提供所有相关的 UI 元素（比如这里的 button），所以 toggle 组件的开发者可能无法满足组件使用者的一些附加需求，比如，在一个自定义的开关控制元素上增加 aria 属性。

Cross-Origin Read Blocking (CORB) blocked cross-origin response [链接] with MIME type text/html. See [链接] for more details.

前些日子有位阿里的大佬发私信询问我是否有意去试试【前端/全栈】的职位，说实话我当时其实是处于懵逼状态的，因为深知自己水平一般，但是还是愿意去试一试的，之后简单沟通后就把自己的简历通过邮件发给了他，然后他告诉我按流程应该很快就会接到预约面试的电话。

现在，Angular Elements 这个项目已经在社区引起一定程度的讨论。这是显而易见的，因为 Angular Elements 提供了很多开箱即用的、十分强大的功能：