国庆节前最后一周在 Code Review 新同学的 React 代码，发现他想通过 memo 和 useCallback 只渲染被修改的子组件部分。事实上该功能在 React 中是难以做到的。因为 React 状态变化后，会重新执行 render 函数。也就是在组件中调用 setState 之后，整个函数将会重新执行一次。

缓存是提升 web 应用程序有效方法之一，尤其是用户受限于网速的情况下。提升系统的响应能力，降低网络的消耗。当然，内容越接近于用户，则缓存的速度就会越快，缓存的有效性则会越高。

随着应用程序的规模增大，对象越来愈多，他们之间的关系也越来复杂。对象间很容易出现相互引用而导致程序无法运行。同时开发者需要改变或者删除某一个对象时候，需要查找并且改造所有引用到它的对象。这样一来，改造的成本会变的非常高。

在项目开发和运行的过程中，总是少不了各类升级。例如某个功能组件需要更高的依赖库、数据项需要进行兼容等等问题。遇到此类问题开发者需要使用版本号来解决。今天我们就来分析一下项目迭代过程中会遇到的各类升级问题以及如何使用版本号来解决。

Million.js 是一个非常快速和轻量级的 ( <4kb) 虚拟 DOM。框架可以通过包装 React 组件来提升性能（该框架目前版本只兼容 React 18 及以上版本）。

在项目开发的过程中，为了减少提高性能，减少请求，开发者往往需要将一些不易改变的数据放入本地缓存中。如把用户使用的模板数据放入 localStorage 或者 IndexedDB。代码往往如下书写。

之前在做 code review 时候发现有同事使用 try catch 包装了一堆异步代码，于是个人就觉得很奇怪，难道不应该只 catch 可能出问题的代码吗？同事告诉我说 try catch 太细的话会出现内外作用域不一致，需要提前声明变量。

在前端开发的过程中，开发者经常会用到 new Date() 来获取当前时间，但是 new Date() 是获取的当前操作系统的时间，由于用户可以修改当前电脑时间，所以它是不准确的。

之前学习函数式编程语言的过程中，有 3 比较重要的特性：函数是一等公民数据不可变惰性求值JavaScript 虽然具有函数式语言的特性，但是很可惜，它还是没有具备不可变数据这一大优势。在开发复杂系统的情况下，不可变性具有两个非常重要的特性：不可修改 (减少错误的发生) 以及结构共享(节省空间)。不可修改也意味着数据...

在开发 web 应用程序时，性能都是必不可少的话题。同时通用 web 应用程序离不开数据的增删改查，虽然用户大部分操作都是在查询，但是我们也不可以忽略更改数据对于系统的影响。于是个人写了一个业务数据比对库 diff-helper。方便开发者在前端提交数据到服务端时候去除不必要的信息，优化网络传输和服务端性能。

笔者曾经开发过一个数据分享类的小程序，分享逻辑上类似于百度网盘。当前数据可以由被分享者加工然后继续分享（可以控制数据的过期时间、是否可以加工数据以及继续分享）。

对于很多项目来说，某些配置项或查询条件是必需的。当用户丢失配置数据或项目下线配置项，都会导致项目发生错误而造成不可用的问题，这时候，开发需要提供一些兜底策略，如当前列表数据查询不到时默认使用第一项。

绝大部分情况，网络请求都是先请求先响应。但是某些情况下，由于未知的一些问题，可能会导致先请求的 api 后返回。最简单的解决方案就是添加 loading 状态，在所有请求都完成后才能进行下一次请求。

队列，在数据结构中是一种线性表，其特性为必须从一端插入，然后从另一端删除数据。但笔者今天重点不是如何实现该数据结构，我们可以看一看如何借助队列管理复杂的任务。

以前我没得选，必须面向搜索引擎。基于 webpack 或 rollup 来一步步构建项目，在开发过程中还有可能发生很多错误。但现在我只想专注于当前业务，挑选合适的脚手架之后迅速构建自己的项目，这样的话，就可以把大量维护性的工作交给开源作者。

可视化领域是目前（泛）前端中最火热的分支之一。无论是面向普通用户的可视化大屏展示数据信息，还是企业服务中数据统计概览或者调度服务，乃至于国家大力推动的智慧建设（智慧大脑，智慧城市）等项目，都重度使用了数据可视化技术。

两年前，我写了一篇关于业务缓存的博客 前端 api 请求缓存方案, 这篇博客反响还不错，其中介绍了如何缓存数据，Promise 以及如何超时删除（也包括如何构建修饰器）。如果对此不够了解，可以阅读博客进行学习。

三年前，我接触了 Immutable 库，体会到了不可变数据结构的利好。Immutable 库具有两个最大的优势: 不可修改以及结构共享。不可修改(容易回溯，易于观察。减少错误的发生) {代码...} 结构共享( 复用内存，节省空间,也就意味着数据修改可以直接记录完整数据，其内存压力也不大，这样对于开发复杂交互项目的重做等功能很有...

在前端项目开发与生产的过程中，“cannot read property of undefined”是一个常见的错误。从不可知得到一个空数据问题在所难免。面对这种问题我们该怎么办呢？

可以看到，当前代码不仅仅提示了当前你输入的配置错误。同时还提供了类似当前输入的近似匹配指令。非常的智能。此时，我们需要使用算法来计算，即模糊集。

目前来说，无论是 to c 业务,还是 to b 业务，对于前端开发者的要求越来越高，各种绚丽的视觉效果，复杂的业务逻辑层出不穷。针对于业务逻辑而言，贯穿后端业务和前端交互都有一个关键点 —— 状态转换。

如果标签仅仅只提供几种颜色可能无法满足各个用户的实际需求。那么系统就需要为用户提供颜色选择。事实上我们完全无法预知用户选择了何种颜色，那么如果当前用户选择了黑色作为背景色，同时当前的字体颜色也是黑色，该标签就无法使用。如果配置背景色的同时还要求用户配置文字颜色，那么这个标签功能未免有些鸡肋。让用...

曾经看过一部网络小说，主角在轮回中的第九世是个大反派。而全书都是主角在努力修炼改变第九世，算是圆满自己的修行。因为一些原因没看完，只是记得书名好像叫做《重修第九世》，但是利用收索引擎却没有找到这本书，应该是我记错了名字。不过就像这本书一样，我相信每个人都有自己没有圆满的事情，有些可以弥补，而有些...

如果使用其他语言开发游戏，无论游戏本身大小与否，我们都需要游戏引擎来帮助我们构建开发，而对于浏览器来说，我们在开发小游戏时候，利用浏览器本身提供的组件和 api 就可以直接进行业务处理，我们也可以更加高效的学习与实践游戏逻辑。同时网页游戏的构建与发布也非常简单。

一份技术规范和他的具体实现必须要做到步调一致。实现先于规范完成不是什么好事情，因为人们会开始依赖这些已实现的细节，这样会对规范造成制约。然而，你也不希望在规范已经完成时还没有任何相关的具体实现与实践经验，因为这样规范就得不到任何反馈。这里面如果存在着无法避免的冲突，而我们也需要硬着头皮去克服了。

9012 年末，作为一个前端，说不了解 Promise 对象用法的基本不存在，这里就不对功能用法进行介绍了。但本文将会讲述你可能不知道的 Promise 3 种奇妙用法。当然，每种用法都会有其适用的特殊场景。

在工程实践中，我们常常会遇到一些奇技淫巧。所谓奇技淫巧，就是官方在设计或者实践中并未想象出的代码风格或者使用场景。其实也就是类似于 react 的 hoc,本来源自于社区，但是该方案却成为了官方肯定的方案。那么究竟应不应在平时学习呢？究竟应不应该在工程中使用呢，或者使用怎么样的奇技淫巧。

如果使用 nodejs,window 可以切换为 global, 代码运行结果不变,因为对于个人而言没有适用场景。于是就没有继续研究下去，可是最近在从新翻阅 es6 时候发现 new.target这个属性。

在没有 前端工程化之前，基本上是我们是代码一把梭，把所需要的库和自己的代码堆砌在一起，然后自上往下的引用就可以了。 那个时代我们没有公用的cdn，也没有什么特别好的方法来优化加载js的速度。最多用以下几个方案。

在开发小程序的时候，我们总是期望用以往的技术规范和语法特点来书写当前的小程序，所以才会有各色的小程序框架，例如 mpvue、taro 等这些编译型框架。当然这些框架本身对于新开发的项目是有所帮助。而对于老项目，我们又想要利用 vue 的语法特性进行维护，又该如何呢？ 在此我研究了一下youzan的 vant-weapp。而发现该...