在项目敏捷开发的过程中，经常会遭遇 Api 联调导致项目开发周期紧张的情况。目前国外很多大型互联网公司流行全栈开发概念，所谓全栈开发即一个项目的前后端逻辑都由一个人来完成。这种模式是的好处是基本上在开发环境没有联调的概念只有 Api 调试的概念。但在目前国内大环境背景下，全栈开发无疑是动了前端或后端工程师的“蛋糕”，所以全栈开发在国内依然是以概念的形式存在。如果前端开发人员利用中间层来处理这个问题，那么是否是一种新的解决思路呢？

之前我有写过一篇优化 vue 项目包大小，提升首屏加载速度的文章，文章中写了一些有关 vue 项目包大小优化的方案，这篇文章则是优化效果的对比实验结果。总的来说，在资源数量提升的情况下，页面加载速度反而有了 10~17% 的提升，这种结果既意外又欣喜，有一种“不明觉厉”的感觉…

在国内大环境的背景下，一些外国网站的访问速度经常会遇到加载慢的情况。这对于前端开发人员而言，最难接受的就是 npm 包下载过慢的问题。你想想呐，一个程序员很开心的写着代码，喝着快乐水，却在下载 npm 依赖时频繁遭遇 Network Error 或 Network Timeout。你那时还有心情写代码么？为了解决广大同僚的工作问题，我有一法可解。

在前端性能优化中有一个很重要的概念-白屏时间。所谓白屏时间，即用户点击一个链接或打开浏览器输入URL地址后，从屏幕空白到显示第一个画面的时间。白屏时间的长短将直接影响用户对网站的第一印象。白屏时间过长还会导致用户流失，降低页面的留存率。

公司的 To C 项目目前采用 vue 开发，使用 vue-cli 构建的项目已经做了不少性能优化，但随着项目的迭代，依然避免不了项目白屏时间过长的问题。为了缩短首页白屏时间，我开始尝试首屏分包加载实验，以下是我的首屏加载优化心得，希望对你有所帮助。

在开发微信页面过程中，有些人可能会遇到跟我相同的麻烦——如何快速调试页面。在微信页面中获取数据（比如，用户昵称和头像）都需要走微信的授权流程。在微信授权之后你可以拿到一个 code，用这个 code 你可以经由后端获取到用户数据。但微信 code 的使用是存在限制的，比如每个 code 只能使用一次，微信 code 获取的域名有白名单限制等。这篇文章介绍了一种在不调整后端逻辑的情况下，解决获取微信 code 过程中的域名白名单验证的问题。

虽然官方允许你直接在前端业务代码中直接使用 Electron 甚至直接引用 Node.js 依赖，但这种方式却对业务无意间侵入了前端业务代码。当项目加载远端业务页面以及业务代码由其他项目打包工具生成的情况下，你可能无法对前端业务代码做修改。如果引入 Native 与 HTML 页面的 Bridge 通信模式，这两类问题将迎刃而解。

Electron（原名为Atom Shell）是 GitHub 开发的一个开源框架。它允许使用 Node.js（作为后端）和 Chromium（作为前端）完成桌面GUI应用程序的开发。Electron 现已被多个开源 Web 应用程序用于前端与后端的开发，著名项目包括 GitHub 的 Atom 和微软的 Visual Studio Code。

Electron 使用 JavaScript 作为基础编程语言，你实际上是在 Chromium 中编写前端代码，在 Node.js 中编写后端代码。随着时代的发展，TypeScript 越来越受到前端开发人员的欢迎，源于 TypeScript 是 JavaScript 的严格超集，不仅包含 JavaScript 的语法，而且还提供了静态类型检查。

React 的数据流是自上而下的，从组件外到组件内，从父组件到子组件，且传递下来的 props 是只读的，如果你想更改 props，只能父组件传入一个封装好的 setState 方法。虽然你可以通过一些方案来解决 React 组件间的通信问题，但随着项目业务的增长，组件通信的成本会越来越高！这时候你可能希望有一处专门负责数据状态管理的地方，而这就是我们今天要提到的数据状态管理库的概念。

在 React 项目中常用的数据状态管理主要有 Redux 和 Mobx。而在早期，React 引入 Redux 需要使用大量的“胶水代码”，且遵循 setState 原则。而 Mobx 主张干掉 setState 的机制，它简化了使用成本，但确增加了“依赖收集”的新概念。这两个状态管理库各有优劣，多年相争不下。

1
2
3
4
5
6

Leader：我们最近好几个项目都有用到相似的业务逻辑，比如，手机验证码注册功能最好能有一个组件库来支持，这样就不需要要多次编写相似的代码了。
Me：我..
Leader：做一个 vue 的组件库应该没什么问题吧。
Me：额..
Leader：我记得你 OKR 里有写到这个。
Me：没问题！

以上内容纯属虚构