GaHingZ 发布的文章

为什么 0.._ 等于 undefined


为什么 0.._ 等于 undefined

前言

今天看文章 为什么用「void 0」代替「undefined」 的时候,

作者提到,用 void 0 替代 undefinded 的原因其中有一点是前者更短,更省空间。

当然最主要的原因还是 undefinded 在局部作用域中可以被重写

下面有人回复 0.._ 长度更短,结果也是 undefinded。 后面解释说是相当于 0['_'],不过没有更深入的讨论了。

当时心中产生了几个问题:

  1. 0.._ 是如何隐式转换成 undefined
  2. 为何(几乎)没有人采用 0.._ 的写法代替 void 0


JS源码解析之Array.prototype.sort


前言

今天有个小伙伴( chrome v59 )遇到一个这样的问题,

[1,2,13,14,5,6,17,18,9,10,11,12,31,41].sort(()=>0)
// [18,1,13,14,5,6,17,2,9,10,11,12,31,41]
[1,2,13,14,5,6,17,18,9,10].sort(()=>0)
// [1,2,13,14,5,6,17,18,9,10]

然后我在自己电脑上( chrome v76 )测试是这样的结果

[1,2,13,14,5,6,17,18,9,10,11,12,31,41].sort(()=>0)
// [1,2,13,14,5,6,17,18,9,10,11,12,31,41]
[1,2,13,14,5,6,17,18,9,10].sort(()=>0)
// [1,2,13,14,5,6,17,18,9,10]

我们知道,给一个 sort 的比较函数中返回0,表示当前比较的两个元素相等

照理说,sort(()=>0) 后数组的元素顺序是不变的,和我的测试效果一致,

那为什么在 低版本的 chrome 上,不同长度的数组运用 sort(()=>0) 后效果不一样呢?


Vue之从零编写一个ContextMenu(右键菜单)插件


前言

ContextMenu 即右键菜单,当前的需求是:右键点击某些组件时,根据所点击组件的信息,展示不同的菜单。

本插件已开源,具体代码和使用可参考: vue-contextmenu

本文采用的是 vue 技术栈,部分处理对于 react 是可以借鉴的

其中需要注意的点有:

  1. 菜单完全显示,即右键点击位于页面下/右侧时,菜单应该向上/左显示
  2. 具体菜单由上层控制,该组件仅提供slot
  3. 该菜单dom上唯一,不需要时应该销毁
  4. 点击页面其他位置,菜单消失

先不考虑插件形式,按日常组件开发


大屏可视化之组件层级设置


前言

最近在进行大屏可视化产品的技术调研,主要是调研 网易有数 和 datav

在组件层级排列这块,两者的实现是不一样的

  • datav:组件均在同级(z-index都是一样的),后定义的属于高层。调整层级就需要移动dom节点位置
  • 有数:根据z-index去设置,调整层级就需要调整自身z-index以及其他受影响的图表 z-index

通过分析vue上两者的实现,比较两者的优缺点