ECharts 作为国内应用最广泛的前端可视化生成工具，提供了丰富的图表展现方式和便捷的图表操作。 ECharts 支持 geoJson 格式的地图，并且官网上提供了现成的 world，china 及全国34个省市自治区地图的下载。这篇文章中我们将会讲解如何使用 ECharts 实现一个中国地图上绘制的散点图。

误区

在设计产品时，由于不少产品经理、工程师并没有「字符不一定等宽」的概念，往往会给出「超过 n 个字符截断显示，英文数字算一个字符，汉字算两个字符」这样的需求。要知道，这里面的问题有很多：

为了显示效果，前端往往会采用优先西文字体族的 font-family 设置，即西文字符用西文字体，汉字用中文字体，这就很容易使得文本的宽度不好根据字符数来控制。首先，非代码的内容本身就不一定适合用等宽西文字体显示。其次即使用了等宽西文字体，汉字也基本不可能正好是其两倍宽。满足这个需求的，只能放弃西文字体，让西文字符也使用中文字体，并且使用中易系列的几个字体了（比如 SimSun，也就是 Windows 下的「宋体」）。（丑不说，还只能满足 Windows 下的需求。）

这种需求甚至在很多时候还会和某些字符编码长度的概念产生混淆，催生「长度限制 n 个字节，其中英文数字算 1 字节、汉字算 2 字节」这样的奇葩说法。

顺便歪个楼，这种「西文等宽、汉字占两倍宽度」的需求正常情况下只会存在于程序员的代码编辑器里。如果你是这种强迫症晚期，又不想用中易宋体，可以考虑试试 Belleve 制作的 Inziu。

思路和原理

对于前端来说，数据库存储的限制不应该是我们需要关心的问题。看下前面的「伪需求」，我们实际的需求往往是从视觉角度出发的「超出特定高度截断显示」或「超出特定行数阶段显示」两种。由于实现方式的差异，其实可以分为「单行截断」、「多行截断」、「按高度截断」几种。从成本和效果来看，有「实现难度」、「效果精确度」、「对内容是否有限制」、「是否能响应页面变化」这些需要考虑的细节。本文里不准备列各种实现的代码，仅谈谈一些相关的问题和思路。

要看一些现有的实现方案可以看这几篇：

原文：https://github.com/blog/2112-delivering-octicons-with-svg

GitHub.com 现在不再使用字体来输出图标了。我们把代码库中所有的 Octicon 替换成了 SVG 版本。虽然这些改动并不那么明显，但你马上就能体会到 SVG 图标的优点。

Octicon 上的对比

切换到 SVG 以后，图标会作为图片渲染而非文字，这使其在任何分辨率下都能很好地在各种像素值下显示。可以比较一下左侧放大后的字体版本和右侧清晰的 SVG 版本。

为何使用 SVG？

图标字体渲染问题

图标字体从来只是一种 hack。我们之前使用一个自定义字体，并将图标作为 Unicode 符号。这样图标字体就可以通过打包后的 CSS 来引入。只要简单地在任意元素上添加一个 class，图标就可以显示出来。然后我们只使用 CSS 就能即时改变图标的尺寸和颜色了。

不幸的是，虽然这些图标是矢量图形，但在 1x 显示屏下的渲染效果并不理想。在基于 WebKit 的浏览器下，图标可能会在某些窗口宽度下变得模糊。因为此时图标是作为文本输出的，本来用于提高文本可读性的次像素渲染技术反而使图标看起来糟糕许多。

对页面渲染的改进

因为我们直接将 SVG 注入 HTML，所以不再会出现图标字体下载、缓存、渲染过程中出现的样式闪动（这也是我们选择这种方式更主要的原因）。

页面闪动

原文：Mixins Are Dead. Long Live Composition

当 React 0.13 推出的时候，大家都震惊了。

它的开篇表达得很明确，mixin 正在逐步退出历史舞台：

不好意思，React ES6 将不再支持mixin，否则有悖 JavaScript 语义化的初衷。

在 JavaScript 中我们找不到通用的标准来定义 mixin，事实上，ES6 也摒弃了不少支持 mixin 的特性。语义混乱的类库已经很多了。尽管我们认为应该有一个统一的方法来定义 mixin，便于对 JavaScript 各种“类”的操作，但 React 并不打算这么做。

mixin 始终会来的，某些人可能会有这样的理解。但实际上， Sebastian Markbåge，伟大的API终结者，也不太看好 mixin：

“坦白说，mixin 其实是一个后门，它可以绕过系统对某些复用的限制，但是语义化的 React 不该是这样的。让组合更加便捷较之随心所欲地 mixin 应该享有更高的优先级，对 React 来说，这才是正事。”

为什么要用 mixin？mixin 解决了什么问题？我们是否可以换一种无继（Tong）承（ku）的方式去解决这些问题？

通用函数

这个例子举得稍微有点脑残。与其用 mixin 的方式去共享通用功能，直接将其提取出来并模块化，需要的时候直接引用不是更好么？

生命周期和状态选择

这是 mixin 的主要用例。如果你对 React 的 mixin 系统还不是特别熟悉，可以这么理解，它"合并"了生命周期钩子并且更加智能。假如同时使用了组合以及一些 mixin 去定义 componentDidMountlifecycle 钩子，React 会自动合并它们以保证每个方法都能被调用。类似地，使用一些mixin也能作用于 getInitialState 方法。

在实践中，这是唯一体现 mixin 用处的地方。mixin 可以向 Flux Store 订阅组件的状态或者作用于更新后的组件 DOM 节点。任何一个组件扩展机制均能获得组件的生命周期，这一点是绝对有必要的。

然而mixin还是有不少弱点：

AMD 为浏览器端开发带来了诸多好处：模块声明、异步加载、依赖管理、bundle等，已经成为很多团队应用开发的标配。在正确的代码下，一切看起来都还好，但是当问题出现时，追查过程通常会令人头疼，此时Loader的提示信息对错误的追查非常关键。ESL 是熊厂应用得比较多的 AMD Loader，本篇blog试图对 ESL 的错误场景与信息提示策略，以及如何追查错误，进行简单的介绍。主要涉及以下3个方面：

1. 模块结构问题
2. 初始化运行中的错误
3. 疏忽导致在模块定义内使用了global require

先厚脸皮求关注。

首先，建议大家在开发中追查错误时，使用 chrome 浏览器的开发者工具。因为它对 re-throw 错误的 stack 跟踪与查看支持得比较好。

在不少框架中，都会对“扩展”这一概念有需求。所谓扩展，即一个可组合的组件，用于嵌入到目标的生命周期中，对目标的行为进行额外的处理使得目标拥有不同的表现。

一个非常简单的案例即日志的记录。通常框架自身并不会有业务相关的日志记录的功能，而业务代码也不希望混入并非业务逻辑的日志记录部分。那么使用一个扩展，在合适的点进行日志的收集和存储是很合适的设计。

在以往，比较流行的扩展通常有几种形式：