看 react 源码过程中，发现这样的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

const NoContext = /*                    */ 0b000000;
const BatchedContext = /*               */ 0b000001;
const EventContext = /*                 */ 0b000010;
const DiscreteEventContext = /*         */ 0b000100;
const LegacyUnbatchedContext = /*       */ 0b001000;
const RenderContext = /*                */ 0b010000;
const CommitContext = /*                */ 0b100000;

let executionContext = NoContext;
executionContext &= ~BatchedContext;
executionContext |= LegacyUnbatchedContext;

if ((executionContext & (RenderContext | CommitContext)) !== NoContext) {
    // We're inside React, so it's fine to read the actual time.
    return msToExpirationTime(now());
}

~、| 和 & 都是「位运算操作符」，平常写代码很少会用到，导致完全不理解这些运算符有什么用，react 源码中这些代码到底是什么意思呢？

目前绝大部分单页应用都由前端控制路由，如react可以使用react-router、vue可以使用vue-router。路由库的使用已经有非常多的文章来介绍，所以本文的重点在于「基于路由配置自动生成导航菜单」，所用技术栈为react + react-router-dom + antd。

为什么是菜单呢？
它绝大部分内容和路由是相同的，但又有部分不同，如果维护两份带来的是巨大的维护成本，只需要修改一处即可同步路由与菜单的变化。

本文目标读者为了解基本的react-router使用，想要在项目中通过路由配置自动生成导航菜单，并正确处理菜单的高亮。

缓存一直以来作为性能优化的一环被广泛使用，

• 数据库缓存
• 代理服务器缓存
• CDN 缓存
• 浏览器缓存

等等，几乎在每一层，都有缓存存在。本篇博客讨论的不是上面这些缓存，而是由我们自己控制的缓存，具体来说是「请求」的缓存，如何优化请求的缓存让我们的应用更好。

现如今我们访问的每个网站，或多或少都会存在「权限控制」。

以一个博客系统为例，系统内共有三种角色

• 1、游客
• 2、会员
• 3、管理员

不同角色支持不同的操作，比如

• 1、游客可以访问博客列表页、博客详情页
• 2、会员除游客权限外，还可以提交博客、提交评论、对博客进行编辑、删除操作等。
• 3、管理员除上述权限外，还可访问用户管理页对用户进行管理。

上述说明「什么用户能够进行什么操作，不能进行什么操作」，可以理解为就是「权限」，根据这些权限，做出正确的处理，就是「权限控制」，而「角色」，是「权限」的集合，也方便我们对用户的定义。

• 一次「错误」的 Promise 实现 - 1

时隔快两月，才产出了第二篇。在实际写博客中，发现Promise实在太难了，初稿在 2/18 就开始写，写到「链式调用」，发现自己还是对原理不够了解，于是耽搁了许久。期间又看了《你不知道的 JavaScript（中卷）》关于异步的部分，深觉自己的浅薄。

我们总是说回调不好用，因为回调地狱，但是回调也可以不写成回调地狱，只是写法问题，如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

foo(function () {
    foo(function () {
        foo(function () {
            console.log('callback hell');
        });
    });
});

// 可以写成这样
function handler1() {
    foo(handler2);
}

function handler2() {
    foo(handler3);
}
function handler3() {
    console.log('callback hell?');
}

foo(handler1);

而且本质上来说，Promise也是回调啊，Promise究竟在内部做了什么事情，让我们非常乐意接受了呢？

Promise在日常中经常用到，并且也能够熟练使用：

1
2
3
4
5
6
7

new Promise((resolve) => {
  console.log('a')
  resolve('b')
  console.log('c')
}).then((data) => {
  console.log(data)
});

上面代码会依次打印a、c、b，对此我们都毫无疑义。

但是为什么呢？我们能自己实现一个Promise库吗？

可视化布局虽然已经发展很久，但一直没有出现被大量使用的平台或工具，而实际上这类需求确确实实存在，那么，这类可视化布局工具到底有没有价值呢？

看到图灵社区的电子书阅读奖励计划，很赞的促进阅读的方式，刚好也在看一些书，所以就有了这篇读后感。

内容不长，两三天时间就能看完。看完后还是有一些意外，觉得自己对于 js 已经算了解，但还是有很多细节方面的知识盲点。经过这次阅读对于 JavaScript 的理解肯定是增加了一些，但更多的是在“学习”方面有了更深刻的认知，学习到如何“学习”。