本文会不定期更新,我遇到的觉得值得分享的 TypeScript 问题都会写在这里

如果你有一些问都不知道咋问的 TypeScript 问题,来这里翻翻或许能找到答案!

互斥类型

2019.09.19 新增

1
2
3
4
5
// https://github.com/Microsoft/TypeScript/issues/14094#issuecomment-373782604
type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never }
type XOR<T, U> = (T | U) extends object
? (Without<T, U> & U) | (Without<U, T> & T)
: T | U

使用上面的 XOR 范型,我们可以很容易地实现如下需求:

话说这次的冠状病毒也太会挑时间和地点了,要在人类迁移和聚集最频繁的节日发生在全世界人口最多的国家!想想当年的非典好像家里人还知道去消消毒,喝喝板蓝根啥的,然而这次我过年刚回去的时候家里好多人竟然都没听说,跟他们说了以后也就是感叹一声,卧槽,这病毒挺来劲的,然后该干嘛干嘛。。

EditorConfig

基本上目前所有编辑器都支持地很完善,拿 vscode 来说,prettier 的配置文件是需要装插件 + 做一定的编辑器设置的。而 editorconfig,装完 EditorConfig for VS Code 就可以了(WebStorm 默认支持),能够很方便地覆盖编辑器的默认格式化。所以它的主要好处其实就在这里,编辑器的默认格式化不同于通过快捷键调用类似 prettier 的三方格式化工具,它能够在比如新建文件,回车换行的阶段就保持正确的代码格式。

这是一个 Web 需求,内容是让用户在列表里「更容易地访问」自己想要访问的资源,类似让网页收藏夹更方便地找到自己收藏的网页这种需求。

首先很容易想到的一个方案是提供一个模糊搜索功能,该方案在列表条目比较多的时候,无疑能带来很高的收益,遂保留之。不过如果用户经常访问的某个页面恰好不在可视区域内,那意味着该用户每次都要滚动视图,或者执行搜索才能访问到它,所以只靠该方案是没办法很好地解决这类用户「更容易地访问」需求的。

那么再思考一下需求本身,对于这类列表数据,什么是「更容易地访问」?

最近帮中台团队面试了很多前端,有些想法不吐不快:发现现在很多前端都喜欢去 ToC 的业务团队,认为 ToB 的业务不就是去 XX 组件库里复制粘贴代码,然后增删改查吗?

但我想说,你那样产出的内容是没有灵魂的!你要说复制粘贴组件库可以帮助你来快速开发我信,但要是指望这种来输出一个好用的管理端我是不信的。

不同的数据用什么组件来承载?不同的操作用什么交互来实现?为什么用的同一套组件库我做的东西就总感觉差点意思?当然了,有的人会说:反正都是给内部人用的东西,能用就得了呗。好吧,只能说人各有志,这种心态来做前端,我是劝不了你的!


觉得土灶这种吃得可能是一种气氛吧

这是去年过年时候去外婆家,做饭的时候一家人在厨房里忙忙碌碌的场景:有洗菜切菜的,有烧火的,有炒菜的,当然了还有一家人的欢声笑语。

即使不参与做饭的,也可以搬个凳子在一旁一手嗑着瓜子,一手撸着小猫小狗,一边还能和「大厨们」聊天打趣,真是能快活到 giào 来 giào 去!

使用场景为增加商品表单,用户确定提交后,继续新增,需要清理之前用户输入数据,并对其初始化,再走一遍组件加载的流程,其中还包括几个子组件,如果手动去处理实在是太麻烦!! - 知乎提问

利用 v-if 控制 router-view,在路由容器组件,如 APP.vue 中实现一个刷新方法

😱 像多线程那样去轮询多个状态,不同的状态满足后去执行不同的定时任务。 项目地址

该状态机基本是为写游戏自动脚本量身定做,它就是整个脚本的”调度中心”。即使是基于 Node.js 的单线程,你也能够实现”同时”检测角色血条,掉落物品,游戏状态等等各种来触发不同的操作,搭配 dm.dll 食用更佳!如下图是本人之前做的流放之路脚本的主框架部分代码: