Chat idea: Office + 前端碰撞出的火花

在论坛里经常看到有些同学询问一些日常办公的问题,比如:

  1. 如何输出 Excel
  2. 如何打印分页 PDF,包括页眉页脚

作为开发人员,在公司里经常被其它部门的同事拜托做一些办公相关的工作,也实属正常。这些非主营业务,做好了,也是蛮有价值的资产。

刚好这两个方面我都有经验,以前也都写过文章分享。不过代码有点年久失修,不知道现在还能不能稳定工作,所以可以考虑利用一次 Chat 的机会把它们修整修整,写写文档,做成工具包直接让大家使用。

继续阅读“Chat idea: Office + 前端碰撞出的火花”

使用 `position: sticky` 的要点

position 属性非常重要,它有五个可选值。“这五个选项是哪些?它们的作用如何?”是我非常喜欢的面试题。以我的经验,凡是这道题答得好的,后面多半没啥问题;这道题答不出或者错漏的,后面能翻盘的概率很低。

属性及释义大家请看 MDN,本文不再赘述。

position: sticky 比较复杂,简单来说,它包含以下特性:

  1. 当它的位置让它可以正常呈现的时候,它的定位等同于 position: static,随着正常的文档流滚动
  2. 当它的位置不足以让它正常显示,但它的父元素有足够多让它显示的空间,它的定位等同于 position: fixed
  3. 当它的父元素的空间不够让它显示,它的定位等同于 position:absolute

言说太复杂,大家可以看下这个演示,基本上就能明白了:

继续阅读“使用 `position: sticky` 的要点”

使用 <wbr> 解决长 URL 的换行问题

问题

我们知道,世界上文字主要有两种:一种是以中文为代表的象形文字;另一种是以英法俄等为代表的拼音语系。前者的换行很简单,每个单字都有自己的意义,所以每个字后面都可以换行。拼音语言,字母组合本身无意义,连在一起才有意义;不同单词意义差异巨大,所以只能以单词为单位换行。

Web 开发中,屏幕宽度有限,超长文字必须换行。在 CSS 中,控制换行的属性主要有 word-breakwhite-space,其中,默认换行行为的是 word-break: normal,即以单词为单位换行。比较奇怪的是,对于 URL,我本以为类似 /.: 都是明显的单词分隔符,理应换行,但实际上,浏览器并不会在这些地方换行。如果我们使用 break-all 或者 break-word,则会使得浏览器在不合理的地方换行,如果刚好在表格里,别的列内容比较多,那么包含 URL 的单元格就会被挤压得非常窄,拉得特别高,非常难看,非常难读。

尝试

原生方法无法解决问题,只好摸索手动断行的做法。但是想完美解决问题非常困难:

第一个方案是全部换行,肯定不行;

第二个方案固定宽度换行,因为表格内容不固定,效果也很差,也不行;

老板提出了第三个方案:使用“8.3”格式,即超长字符串只保留前8个字符,后面显示“…”,然后可以手动展开。很明显,这个方案对 URL 来说没有什么价值,https:// 加起来正好 8 个字符,有意义么……即使加长也一样,因为用户有时候看域名,有时候看 pathname,也有时候看 search,我们没有办法预测。

然后老板又提出“Excel 方案”,即固定列宽,自动隐藏超出的文字,用户可以通过拖拽来调整列宽。这个方案理论上可以解决问题,但是实现难度太大,因为浏览器自带表格自适应宽度的算法,采用 “Excel 方案” 就必须放弃这个算法自己手动实现,成本很高,非万不得已也不想做。

最后,动态换行,根据表格宽度计算在哪里断行。还是不行,计算难度太大。

<wbr> 解决

这个问题困扰了我很久,直到前两天,我突然发现原来有 <wbr> 软换行的存在。而且它的兼容性非常之好,甚至连 IE8 都支持。

它的含义是“可换可不换”。当元素宽度不够需要换行,就从它这里换;如果宽度够,就不换行。所以,只需要在“可能”换行的地方加上这个元素,就可以达成我的目标。写成代码很简单,大约是这样:

function wrapUrl(url) {
  if (!url) {
    return '';
  }

  // 先把协议取出来,我不希望在协议这里换行
  const head = url.substring(0, 10);
  const left = url.substring(10);
  // 在 `?&/` 前面插入 `<wbr>`
  // 或者16个连续英文数字也要换行,打断 hash 和 md5
  return head + left.replace(/([?&\/]|([a-zA-Z0-9]{16}))/g, str => '<wbr>' + str );
}

实际效果很好,大概是这样(截图时,<wbr> 放在断开位置的后面,我觉得不好看,就调整了下):

<br> 对比,后者是固定换行,当表格内容很少,有充足的空间显示 URL 时,也会换行,就不合适了。

总结

需要注意,<table> 的渲染很特殊,浏览器要花很多时间计算每个列的内容、计算它的宽度,所以性能会比较差,这也是不要用 <table> 做布局的原因。本案例中,使用 <wbr> 实际上是想借用浏览器计算表格各列宽度的机制。所以是合适的。表格渲染之后,内容最好就固定住,不要有复杂的变动,比如隐藏/显示(前面说的8.3格式),因为内容的变化会导致浏览器重新计算布局重新渲染,比较消耗机器的性能。

以及,做了十几年前端,稍一放松,竟然有完全不清楚没用过的标签,看来有必要找时间再把 HTML、CSS 再翻一遍了。

GitChat: 使用 webpack 开发企业官网

最近我厂官网改版,我尝试用 Webpack 重建了开发工具链,效果不错,配置代码少了很多,逻辑更加简单清晰。我觉得值得拿出来分享一下。

最近我厂官网改版,我尝试用 Webpack 重建了开发工具链,效果不错,配置代码少了很多,逻辑更加简单清晰。我觉得值得拿出来分享一下。

文章已经发布,慢慢写了将近5w字,干货很多,覆盖面很广,欢迎大家前去阅读:升级工具链吧!使用 Webpack 开发企业官网。感谢大家的支持。

交流应该会通过直播进行,暂定7月中吧,斗鱼直播间:douyu.tv/meathill。

继续阅读“GitChat: 使用 webpack 开发企业官网”

Intersection Observer 笔记

最近用 Intersection Observer API 解决了一个小需求,记录一下用法。

有时候我们需要根据一个元素的位置来修改它的属性,比如图片的 lazyload,比如视频离开视窗之后停止播放。

以前的做法通常是:

  1. 侦听 window.scroll 事件
  2. scroll 触发,遍历每个要检查的 DOM Element,执行 .getBoundingClientRect() 取出它的 widthheighttopleft,然后根据 viewport 和宽高 scrollTop scrollLeft 计算对象是否应该出现
  3. 然后做处理

这样做会产生一些问题:

  1. 如果漏掉移除侦听器,可能造成内存泄漏
  2. 不同组件之间,很难共享侦听器
  3. 每一次都计算所有 Element,成本很高

于是现在我们有了 Intersection Observer,专门用来观察一个 Element 是否出现在 viewport 或者父容器里。它可以很好的解决这些问题:

  1. API 更清晰
  2. 逻辑原生,速度更快,消耗更少
  3. 可以自定义阈值,更加可控

关于 Intersection Observer 的详细知识,建议大家认真阅读 MDN – Intersection Observer,我就不抄文档了。

使用 Intersection Observer 大体上分为三步:

  1. 声明一个 Intersection Observer 实例,这一步最关键的是要确定显隐依据哪个元素,也就是 root
  2. 将需要检查的元素加入侦听队列
  3. 在回调函数里处理元素状态

写成代码大概是这样的:

// 声明一个实例
// 因为我的视口即当前 viewport,所以这里不需要 `options`
const observer = new IntersectionObserver(entries => {
  // 遍历所有实例,如果它显示出来,即 intersectionRatio 显示比例大于 0
  // 那么就让它 `dispatch('visible')`
  entries.forEach(({target, intersectionRatio}) => {
    const event = new CustomEvent('visible', {
      detail: {
        isVisible: intersectionRatio > 0,
      },
    });
    target.dispatchEvent(event);
  });
});

// 然后可以在 Vue 里侦听这个事件
export default {
  template: '<div @visible="onVisible"></div>';
}

Intersection Observer API 公布一段时间之后,又进行了升级,现在支持更丰富的参数,比如我们可以定义一个函数去判断更复杂情况下的显示状态。不过大部分场景下,我们并不需要很精准的判断,所以我觉得这个只是保障选择的机会。


参考阅读:

Proposed Updates for Intersection Observer

Node.js 里使用 Promise 的小技巧

Node.js 8 的时候,引入了 util.promisify() 方法,可以把 node-like 的回调函数改造成返回 Promise 实例的方法,我当时还写了篇博文《Node.js 8 中的 util.promisify》小记。

所以我现在写 Node.js 基本都是这种风格:

const fs = require('fs');
const {promisify} = require('util');

const readFile = promisify(fs.readFile);
const writeFile = promisify(fs.writeFile);

刚才在推上看到两位大佬聊起这个话题,发现可以这么搞:

去查了一下 Node.js 的文档,发现这是 v10 新增的 API,如今应该大部分环境都可以用了。

Chat Idea:扫雷网页版实战

最近最常玩的游戏是扫雷。年纪大了,干什么时候都先考虑成本,游戏也是如此。扫雷的成本最低,倒不是说购买成本,而是启动、游戏、退出之类的成本。

可惜的是,经典版扫雷已经从 Windows 10 里移除了,现在只能通过 Windows 应用商店装一个很复杂的扫雷游戏,花样多了很多,却并不好玩。所以我现在多半玩网页版。

玩着玩着,出于程序员的本能,我就开始考虑如何写这个游戏,逻辑不算复杂,功能点也不多,好像蛮适合做成“实战派”教程的,比如用 Grid 写界面,项目结构就用 Vue CLI 3 吧,然后部署的话前端纯静态就够了。

那么就愉快的决定了吧,把这个项目做出来,把中间需要的知识,用到的技能、工具,可能会遭遇的问题记下来分享出来,写成一篇文章,分享出去。读完整篇文章,你将学会:

  1. 使用 Vue CLI 3 搭建项目
  2. 使用 CSS Flex + Grid 完成页面布局
  3. 扫雷游戏的逻辑
  4. 使用 Vue 完成游戏逻辑
  5. 记录成绩
  6. 部署和分享

目标读者:

  1. 初级开发者,能看到一个项目的成型
  2. 希望了解现代化前端框架、工具链

Chat idea:记一次 Firefox 下 Vue 带来的性能危机的解决

前两天遇到一个问题:我厂的一个产品在 Firefox 下,可能发生因为 CPU 占用过高而卡死的情况。这个问题在测试环境不复现,在 Chrome下基本上也不会复现。

因为我厂老板是这个产品的主要用户,这个 bug 让我倍感压力,但一直没有解决它的好办法。终于有一天,在某台生产机上调试另外一个 bug 的时候,我终于发现了稳定复现这个 bug 的方式。

接下来就是几个小时的 debug,然后发现问题所在,然后解决问题,然后发现解决方案不理想,于是寻求新的解决方案,然后找到新的 API,最终彻底的解决这个问题。

接下来我就分享这个过程,读完整篇文章当中你将学会:

  1. 使用开发者工具查找性能问题
  2. 不断切分,缩小问题范围
  3. 理解 Vue 响应式原理分析问题根源
  4. 修复问题并验证
  5. 新的解决方案 Intersection Observer
  6. 解决问题并上线

目标读者:

  1. 中级开发者
  2. 熟悉原生 JS

大家觉得这个 idea 如何?请留言告诉我。不出意外的话这将是我下个月的 gitchat 内容。

Stylus 实现 `content: “5”`

一般来说 Stylus 对属性是直接替换的,所以正常来说下面的 stylus

$a = 10

.foo::before
  content $a

会编译成:

.foo::before {
  content: 10;
}

这样是非法的,10 不会渲染出来。如果想让它渲染出来,必须用字符串。如果只有一个值,那就好办了,直接 $a = '10' 就好。但如果在循环里,就比较麻烦,此时,可以用 '' + 10 转换成字符串,或者使用 s(template, value),以下两种方式是等效的。

// 注意运算顺序哦
.foo
  for n in 1..5
    &:nth-child({n})::before
      $str = '' + (5 - n)
      content $str

  for n in 1..5
    &:nth-child({n})::after
      $str = 5 - n
      content s('"%s"', $str)