本文首发于知乎 前端精读评论 专栏

本期精读文章是：How to safely use react context

1 引言

在 React 源码中，context 始终存在，却在 React 0.14 的官方文档中才有所体现。在目前最新的官方文档中，仍不建议使用 context，也表明 context 是一个实验性的 API，在未来 React 版本中可能被更改。那么哪些场景下需要用到 context，而哪些情况下应该避免使用，context 又有什么坑呢？让我们一起来讨论一下。

2 内容概要

React context 可以把数据直接传递给组件树的底层组件，而无需中间组件的参与。Redux 作者 Dan Abramov 为 contenxt 的使用总结了一些注意事项：

• 如果你是一个库的作者，需要将信息传递给深层次组件时，context 在一些情况下可能无法更新成功。
• 如果是界面主题、本地化信息，context 被应用于不易改变的全局变量，可以提供一个高阶组件，以便在 API 更新时只需修改一处。
• 如果库需要你使用 context，请它提供高阶组件给你。

正如 Dan 第一条所述，在 React issue 中，经常能找到 React.PureComponent、shouldComponentUpdate 与包含 Context 的库结合后引发的一些问题。原因在于 shouldComponentUpdate 会切断子树的 rerender，当 state 或 props 没有发生变化时，可能意外中断上层 context 传播。也就是当 shouldComponentUpdate 返回 false 时，context 的变化是无法被底层所感知的。

因此，我们认为 context 应该是不变的，在构造时只接受 context 一次，使用 context，应类似于依赖注入系统来进行。结合精读文章的示例总结一下思路，不变的 context 中包含可变的元素，元素的变化触发自身的监听器实现底层组件的更新，从而绕过 shouldComponentUpdate。

最后作者提出了 Mobx 下的两种解决方案。context 中的可变元素可用 observable 来实现，从而避免上述事件监听器编写，因为 observable 会帮你完成元素改变后的响应。当然 Provider + inject 也可以完成，具体可参考精读文章中的代码。

3 精读

本次提出独到观点的同学有：@monkingxue @alcat2008 @ascoders，精读由此归纳。

context 的使用场景

In some cases, you want to pass data through the component tree without having to pass the props down manually at every level.

context 的本质在于为组件树提供一种跨层级通信的能力，原本在 React 只能通过 props 逐层传递数据，而 context 打破了这一层束缚。

context 虽然不被建议使用，但在一些流行库中却非常常见，例如：react-redux、react-router。究其原因，我认为是单一顶层与多样底层间不是单纯父子关系的结果。例如：react-redux 中的 Provider，react-router 中的 Router，均在顶层控制 store 信息与路由信息。而对于 Connect 与 Route 而言，它们在 view 中的层级是多样化的，通过 context 获取顶层 Provider 与 Router 中的相关信息再合适不过。

context 的坑

context 相当于一个全局变量，难以追溯数据源，很难找到是在哪个地方中对 context 进行了更新。
组件中依赖 context，会使组件耦合度提高，既不利于组件复用，也不利于组件测试。
当 props 改变或是 setState 被调用，getChildContext 也会被调用，生成新的 context，但 shouldComponentUpdate 返回的 false 会 block 住 context，导致没有更新，这也是精读文章的重点内容。

4 总结

正如精读文章开头所说，context 是一个非常强大的，具有很多免责声明的特性，就像伊甸园中的禁果。的确，引入全局变量似乎是应用混乱的开始，而 context 与 props/state 相比也实属异类。在业务代码中，我们应抵制使用 context，而在框架和库中可结合场景适当使用，相信 context 也并非洪水猛兽。

讨论地址是：精读《How to safely use React context》- Issue #23 - dt-fe/weekly

如果你想参与讨论，请点击这里，每周都有新的主题，每周五发布。

本文首发于知乎 前端精读评论 专栏

本期精读文章是：React Higher Order Components in depth

1 引言

高阶组件（ higher-order component ，HOC ）是 React 中复用组件逻辑的一种进阶技巧。它本身并不是 React 的 API，而是一种 React 组件的设计理念，众多的 React 库已经证明了它的价值，例如耳熟能详的 react-redux。

高阶组件的概念其实并不难，我们能通过类比高阶函数迅速掌握。高阶函数是把函数作为参数传入到函数中并返回一个新的函数。这里我们把函数替换为组件，就是高阶组件了。

const EnhancedComponent = higherOrderComponent(WrappedComponent);

当然了解高阶组件的概念只是万里长征第一步，精读文章在阐述其概念与实现外，也强调了其重要性与局限性，以及与其他方案的比较，让我们一起来领略吧。

本文首发于知乎 pure render 专栏

毫无疑问，Redux 与 MobX 是 React 生态中最火热的状态管理工具，社区也一直没有停止对上述两者的讨论。近期，团队小伙伴 黄子毅 的文章 Mobx 思想的实现原理，及与 Redux 对比，以及正在与我一起翻译 MobX 中文文档 岳逢楽 同学的 如果用Redux不爽的话，那就试试MobX吧，都对此发表了自己的观点。在不久前结束的 React Conf 2017 中，Preethi Kasireddy 也做了相关分享，MobX vs Redux: Comparing the Opposing Paradigms，让我们来看看她的观点是怎样的。

尽管 Email 中的 HTML 与我们在平时写的 HTML 并没有本质上的区别，但由于受到不同客户端渲染方式不同以及邮件安全性限制的影响，让我们在编写邮件模版时，一夜之间回到解放前。只能使用 Table 来布局，不能运行 JavaScript 脚本，不能使用外联的 CSS，图片是唯一可以引用的外部资源等等。当然这些并不是本文讨论的重点，如果感兴趣，可以参考下列文章或互联网上的更多资源。

创建坚如磐石的HTML邮件
HTML Email 编写指南

最近，我需要编写的邮件模版并不是 EDM (以营销为目的的电子邮件)，而是系统自动发送的统计报表邮件。因此并不需要非常绚丽，但是由于承载了一段时间内重要数据的显示，单纯的数字显得过于苍白，便希望插入一些图表来丰富。上文已经提到过了，电子邮件最多可以插入图片，平时用来制作图表 SVG、Canvas 就英雄无用武之地了。

在数据可视化中，我们往往会使用图来表达数据中所蕴含的信息。而图布局算法可以使散乱的信息 (信息多以点线的关系承载) 通过一种清晰的方式呈现出来，并符合相应的美学标准。在图布局算法模型中，其建立在粒子物理理论的基础上，将节点模拟成为原子，通过原子间的引力和斥力来得到节点的速度与加速度，计算其移动方位与距离，最终达到一个稳定平衡的状态，从而完成布局。以下就是由 d3 实现的力引导布局:

在 d3 的实现中，为了达到性能与效果的平衡，节点与节点间模拟同种电荷相互排斥，并将节点存入四叉树中，利用 Barnes–Hut 近似来减少节点间电荷斥力的计算量。同时连线间的节点模拟弹簧牵引力，节点的速度综合斥力引力得出，并发生阻尼衰减，最终达到整图平衡。

在本文中，我们将对 d3 实现的力导引布局进行一步步分解，详细剖析其实现过程与背后的原理。在此之前，读者们自行阅读上图实现源码，熟悉一下 d3-force API。

本文首发于知乎 pure render 专栏

在前端业务开发中，组件化已经成为我们的共识。沉淀和复用组件，是提高开发效率的利器。但在组件复用的过程中，我们往往会遇到这样的问题，组件相似，却在结构或交互上有些许差别，需要对组件进行改造方可满足需求。这个问题之前在 React实践 - Component Generator 就有所提及。

之初，我们提出了组件配置式。在业务统一的情况下，仅仅修改组件用于配置的 props 就可以满足业务需求。但随着业务发生变化导致组件形态发生变化时，我们就必须不断增加配置去应对变化，便会出现配置泛滥，而在扩展过程中又必须保证组件向下兼容，只增不减，使组件可维护性的降低。

最近的项目开发中，Jason 提出了组件组合式开发思想，有效地解决了配置式所存在的一些问题。下面我将详细阐述其思想与具体实现。