唐霜的博客

我们有如下一个联合类型：

type union = { a: string } | { b: number } | { c: boolean }

如何得到最终的类型：

type obj = {
  a: string
  b: number
  c: boolean
}

如果是用js来写，不要太简单，但是typescript没有对union的遍历能力，所以只能走其他办法，经过探索后最终得到如下解：

type GetUnionKeys<Unoin> = Unoin extends any
  ? {
      [key in keyof Unoin]: key;
    } extends {
      [key in keyof Unoin]: infer K;
    }
    ? K
    : never
  : never;

type UnionToInterByKeys<Union, Keys extends string | number | symbol> = {
  [key in Keys]: Union extends any
    ? {
        [k in keyof Union]: k extends key ? Union[k] : never;
      } extends {
        [k in keyof Union]: infer P;
      }
      ? P
      : never
    : never;
};

type UnionToInter<Unoin> = UnionToInterByKeys<Unoin, GetUnionKeys<Unoin>>;

在使用时如下：

type obj = UnionToInter<union>

这样就可以实现我们的目的。我写了两个原子范型，GetUnionKeys用于获取联合类型里面的全部key，UnionToInterByKeys是关键，用于基于前面获得的keys再得到最后的对象。

不过这个方法存在一定的风险，假如联合类型中存在相同的属性，那么可能存在不确定性，比如：

type obj = UnionToInter<{ a: string, b: number } | { b: boolean }>

我们最终就会得到：

type obj = {
  a: string
  b: number | boolean
}

但是我们再开发中，常常会让后面一个覆盖前面的，我们期望得到的是:

type obj = {
  a: string
  b: boolean
}

我之前在读一些博客的时候，有同学提到可以通过冲载机制得到联合类型中的最后一个元素，但是我没有找到这篇文章，如果你看到，请在下方留言给我。

通过window的popstate事件可以监听history的变化，但是，“popstate会在浏览器前进后退操作、history.go/back/forward调用、hashchange的时候触发”，它是一个复合事件，你根本判断不了到底是哪种情况引起的popstate。更难理解的是，我不知道为什么要把forward也设计为popstate，pop这个词的意思不就是从stack顶把最上面的一个从栈中移除么？forward明显是push的行为，怎么也放到popstate里面。这个事件明显是有设计缺陷的。回到题目，我们怎么去判断用户是点击了“退回”按钮？

我们要用到一些取巧的办法。具体我总结为3步：

• 充实history stack，以提供更多信息让我们可以在用户刷新浏览器的情况下，仍然获得上下页信息关联
• 为history创建一个私有的记录值，用以区分history当前的state和上一个state（我们在事件回调中只能拿到当前state）
• 通过第一步和第二步铺垫的内容，在回调函数中进行判断，从而判断是否是用户点击了“退回”按钮

接下来我们进行实施。在此之前，我们需要了解一些简单的知识。history是浏览器用户记录用户浏览器历史的全局对象，既然是“浏览历史”，那么就是一组单一数据的列表（有顺序），这个所谓单一数据，就是其内部的state概念，一个state表示用户在浏览一个界面（对应一个url）时留下的痕迹，不过，这个state必须由开发者定义，如果开发者不定义，那么state就是null，而且为null的时候，就没哟意义。注意，浏览器不会主动帮你记录当前的url，虽然它自己记录在了浏览器内部，你可以通过浏览器的“浏览历史”功能查看，但是，你无法在代码层面直接读取这些历史记录，你只能读取history当前的state，即通过 window.history.state 来读取，当然，你也可以通过 window.location 来读取当前的url信息。“只能读取当前的”，也就意味着这是一种栈结构的数据管理，而且，这个栈在用户刷新当前浏览器tab时，仍然是维持的。

基于这一特性，我们可以自己在state栈中，构建一个链表结构，从而可以读取整个栈内的state链。具体怎么做呢？

我们知道history有pushState和replaceState两个接口，对于SPA应用而言，整个应用中只会使用pushState和replaceState两个接口进行url的跳转（还有一种是在a标签href中使用#触发，例如 <a href="#/base/xxx"> 这种也可以做到无刷新的界面跳转，但是由于它走另外一个体系，也就是hashchange的体系，是比较老的技术，现在大部分框架都是基于state的体系来做，因此，我们本文不考虑hashchange这种方案），因此，我们可以对这两个接口进行改造，从而在跳转时，对state进行信息充实。

const originalPushState = history.pushState.bind(history);

// 要求在调用pushState时state必须是一个对象
history.pushState = function(state, title, url) {
  const { state: currentState } = history; // 获取未跳转之前的state，也就是当前的state
  const nextState = state || {};
  nextState.prevState = currentState;
  originalPushState(nextState);
};

通过这一改造，我们重写了history.pushState，这样我们就让每一个被push到state栈中的state拥有了prevState属性，通过该属性就可以形成一条反向链表，用以追踪state之间的关系。

接下来，我们创建一个私有的变量，用来记录history.state发生变化前的state.

let latestState = history.state;

window.addEventListener('popstate', () => {
  const prevState = latestState;
  const { state } = history;
  latestState = state;
  ....
})

在每一次popstate被触发时，我们去修改latestState，这样，我们就可以记录在state发生变化前的state是哪一个。

最后，我们通过latestState和当前的state进行对比，来猜测用户是否点击了“退回”按钮。

window.addEventListener('popstate', () => {
  const currentState = latestState;
  const { state: nextState } = history;
  latestState = nextState;

  if (currentState?.prev === nextState) {
    // 用户点击了“退回”按钮
  }
})

当变化后的state正好是变化前state.prev时，我们就认为用户点击了“退回”按钮。当然，这里有一个点需要提前预设，因为在不同的SPA框架中，触发popstate的可能包含在代码中调用history.back()和history.go(-1)的情况，所以，在代码层面，需要继续去区分到底是程序里调用.back还是用户点击“退回”按钮。区分方法也很简单，你可以重写back和go方法，在里面做一个标记，从而在判断时增加对该标记的判断。

最近在调试的时候，同事反馈说图片没有展示出来，去看了以后简直莫名奇妙，因为我自认为对css-loader和file-loader的配置没有问题，难道css-loader又挖了什么坑？于是开始漫长的调试，测试过程。最终发现，问题是真的存在，而且我google了半天，恁是在国内外都没有找到靠谱的解决方法。调试过程中可以肯定的是，css-loader竟然自己把url()的图片生成到目录下了，然后file-loader又做了一遍：

这也就意味着一张图片被处理了两次，具体造成的问题是css-loader给的路径不对还是file-loader给的不对，就不想去深究，总之就是两个loader冲突了。按照我以前的理解，css-loader只负责把url()转化为require()的形式，并不负责生成真实的图片，然后file-loader可以识别require(image)的形式，并生成图片，两个loader分工明确。那么这里是为什么呢？于是，我把file-loader从rules中去掉，然后……图片竟然展示出来了！！

所以说，无论是css-loader的问题，还是结合webpack5一起的问题，现在webpack5+新版css-loader就可以自己把图片处理到目标目录下了。然而，问题在于，如果去掉file-loader，那么我们在js中是没有办法直接import一张图片作为url来使用的。这就矛盾了。而且检查了file-loader的配置，也没有接口可以让我们忽略对css文件中的图片进行排除。似乎就这样卡住了。

于是重新回去阅读文档。

果然，不独不知道，webpack5现在已经牛x到自己可以把非js的文件资源作为模块读取了。什么？不懂？意思就是，不需要file-loader了，webpack内置了工具！具体做法就是把我们配置文件中的 loader: 'file-loader' 一句改为 type: 'asset/resource' 就可以了。

webpack的rule.type在v4中就已经加入了，只是很少被用到，它的文档也说的不清不楚，我也不知道它有这个能力，而 asset/resource 也是到v5才悄悄加进去的，你可以查看v4的文档和v5的文档的差异。

新增的asset这个选项就是对非js相关的资源的处理，它文档单独通过一节对这些项目进行解释，而且里面就明确提到可以代替以前的file-loader, url-loader, raw-loader，然而，大哥你虽然可以代替，但是直接破坏原来的效果，是不是有点不厚道呀！

在项目中，我们不仅要管理js代码，还要管理css代码，但是我们现在业界对js研究的比较多，对css比较少，不过这两年我注意到已经有不少有关css的新思想。不过，抛开这些新东西，我们的项目中，应该怎么管理我们的css呢？我做了调研，大致结果如下：

实际上，没有哪一种是最好的，只有适合不适合。对于我个人而言，样式隔离是一个必须选项，因为我开发工具库比较多一些，我提供库给别人用，别人可能还会使用其他人的库，两个库之间撞名的情况很容易发生，所以，隔离对我来说非常重要。在考虑到各种场景后，我最终使用css modules比较多，在nautil中我就坚持css和css modules一起用。不过，除了隔离之外，复用性就不是很好，因为很少能复用其他库的样式，最终会导致使用了我的库的站点，css代码量可能会篇多一些。所以我说，没有那个最好，只有最适合。

已经很久没有更新博客的内容了，便随意写点什么。最近经历了工作上的很多事，有了一些感悟。但是我不会一条一条的列出来，也不会说我经历了什么。感悟这种东西，它不一定对其他人有用，或者说你并不认同。但是，有些东西，表面上的差异，本质上是一致的，感悟这类东西，就往往是表面的，深层的东西埋在感悟下面，更加世俗，更加有价值，但是却失去了一些浪漫。所以，从这个角度去想，我这个人还是有一点浪漫主义，但是我也并不稀奇，毕竟浪漫是不能当饭吃，很多人可悲的是，在生存的边缘挣扎，却在追求极致的浪漫主义。

我不能完全体会到“命运”，但是呢，最近在网上看到一些知名的，但是不像是装出来的名人，他们多次提到“信命”这个事情。我也深刻理解到，“命”不是迷信，更多的是对生命的敬畏，有所为，有所不为。信命的人总是带着这种敬畏，所以看上去总是蹑手蹑脚，但是他自己在其中并不觉得可惜，并且总能做到脚踏实地问心无愧。而不信命的人，往往追求“我命由我不由天”，所以往往比较激进，甚至不惜代价去冲击，有的跳跃了，有的败下来，但是，当这些过去之后，他们总是会有诸多遗憾，甚至内心惭愧悔恨。所以，我的感悟总结起来就一句话“尽人事以听天命”。也就是跟着命运的方向走，在这个过程中自己张开翅膀享受这个过程。这里面所遇到的困难，有的时候很痛苦，但是总是会在之后获得内心的慰藉。一时的得失也好，所谓的人生重大决定也罢，都不是特别重要，关键是，当这件事摆在你面前的时候，不逃避，而是去积极准备和面对它。

你说我信命，但我并不信，我只是遵从了一种理念去生活，是积极的，和那些信命躺平的是截然相反的。不过，我也因此知道，并不是任何努力都有你想要的结果，在这里面，95%的努力是没有用的，这些努力仅仅是你付出的信仰，只有剩下的那5%是有用的。但是，你可能会说，现在那么多人一朝就翻身了，难道是因为遵从你这套理论吗？当然不完全是，但是，他们的命和你的命不同，所以你的努力和他的努力不同。就像我一样，我时常会觉得不公平，有些人明明能力不如我，思想不如我，甚至品德不如我，为什么却比我混的好，赚的钱比我多。然而，当我回过来，并不是我不够好，而是在这个世界的规律里面，在我们这条通道里，他才是适应规律的，就像管道里顺着水流的枯叶，虽然已经腐败不堪，但是和逆流而上的水虫而言，却是更早离开管道看见阳光。我们越是挣扎，或许里得到越远。但我们是没有办法做枯叶的，每个人的性质不同，我们是金子，沉在水底，纹丝不动，永不见光明，这是我们骨子里的倔强决定的，不是可以改变的。所以，即使我们心想我们可以同流合污，最后还是发现不可能得到。这就是命。

那我们就不作为，也是不可取。信命是积极的，信命总是往前，因为信命会顺其自然，尽人事以听天命，而不信命则不然，会逆天而行，所以消耗的更快，看上去轰轰烈烈，实际上很快弹尽粮绝。不过，奇怪的是，竟然有人把“就是死了，也要轰轰烈烈”当作格言，甚至人不在少数。我想，这样的人归根结底，是内在的病态，也是一种性质，就是逆流而上的性质，非要挣扎，一身伤残。这样的人自然是可以存在，但是性质不是这样的人，不该去学，世界上大部分人都是水流地下的泥沙，不快，但总归还是会随着水流慢慢前行，而若这些人非觉得要不一样，那他们只会成为逆流而上的那种，而不可能顺流而下的那种，逆流而上本质上是降级，是更容易的事，而泥沙的性质不可能升格为枯叶般轻快，这是性质决定，但非要降级自己的性质，终究会消散在时间里。

今日就讲这么多，并不值得去深入。