快捷动作（可选的）：emoji的子集，用于快速回复消息。
React为编写无状态组件提供了两种方式：PureComponent类和function。function更为简单一些，不过它们在每次合并时都会进行渲染，会影响性能。React团队计划对function进行优化，不过目前最好还是避免使用它们。于是我们选择了PureComponent，它预定以了shouldComponentUpdate方法，这个方法可以防止在遇到相同属性时进行更新操作。
React是一个视图层，把它与自己开发的应用集成要比把它与标准的框架集成直截了当得多。我们不应该破坏Emoji选择器的封装性，这样才能很好地与Slack现有的模式集成在一起——我们希望这个组件就像是从一个端到端的React应用里拿出来的一样。为了保持选择器的纯净，我们在现有的模块系统里创建了一个轻量级的适配器。适配器挂载选择器组件，抽取模型数据，并监听来自外部的信号。采用这种模式，我们可以在开发新功能的同时逐步地迁移代码库。
新的开发流程
虽然使用React进行开发是一件很愉悦的事情，但将它集成到我们已有的开发流程里却不是那么一回事——至少在一开始不是那么令人愉快。在那个时候，Slack使用的是自己开发的前端构建管道，没有所谓的导入、依赖或者复杂的转换（比如transpilation）。我们决定采用JSX语法和ES2015+，并使用Babel和webpack在本地构建Emoji选择器的资源。
我们预期签入本地编译的代码会很痛苦，但我们低估了接连发生的合并冲突和依赖管理问题是多么令人抓狂。最后，我们尝试将webpack集成到我们的开发和staging环境里，目标是无缝地替代已有的工作流。为此，我们做了如下的工作。
通过重写Emoji选择器，迫使我们反思我们的构建管道如何能够以一种更健壮、更具伸缩性的方式打包资源。
性能
我们在少量的团队里部署了新的组件，并观察结果。我们观察了Emoji选择器在用户使用不同的5种交互方式下的渲染速度，对于大部分的操作，React表现出了显著的速度提升。以下列出了选择器在正常规模团队里的不同渲染时间。
第一次挂载：-270毫秒（减少了85%）
第二次挂载：-158毫秒（减少了91.3%）
搜索（多个结果）：+27毫秒（增加了259%）
搜索（一个结果）：-25毫秒（减少了53.2%）
重置搜索：-68毫秒（减少了70.1%）
最大的改进来自“第一次挂载”，从318毫秒到48毫秒，减少了270毫秒，也就是85%。这要极力归功于react-virtualized——一个虚拟列表代码库——减少重新渲染emoji的数量。在默认视图上，React Emoji选择器比DOM少渲染了85%。
或许最让人感到吃惊的变化来自“搜索（多个结果）”，时间从17毫秒增加到了44毫秒，增加了27毫秒。旧选择器只是把不匹配的emoji隐藏起来，也就是说，当匹配到大部分emoji时会相对较快。但它的缺点也是显而易见的，“搜索（一个结果）”和“重置搜索”就让它的缺点原形毕露，因为此时它需要隐藏更多的emoji。
未来
使用React重写Emoji选择器加快了渲染速度，同时简化了代码，让代码更容易维护。我们正在使用React重写剩余的代码。我们还有很多工作要做，这次重写将为用户的日常体验带来积极的影响，为此我们感到非常兴奋。与此同时，我们积累了React的实践经验，可以帮助平台更进一步。