React 标识符极难看。我不是在谈及那个架构的任何控制技术优点；我说的是简单的后现代，标识符在我萤幕上的模样，以及它所唤醒的感觉。

标识符后现代一般来说并不是开发者关注的难题。我们要念旧更重要的难题。后现代是主观的，很难来衡量，追求它的好处也并不明确。你极少会看到两个开发者高声在站讨论会上告诉他们的同僚他们对标识符在萤幕上的模样不满意。我不确定是否有人会这么做，但我的看法有所相同。

我是在从事两个本业工程项目时，开始考虑 React 的耐用难题的。做为绝大多数以代码为职业和嗜好的开发人员，工作和消闲之间的区别是由你所享受到的快乐所决定的。总之，我们的生涯最终目标是让这二者完全一致，虽然有时候这二者是完全一致的，但当这二者不完全一致时，你仍然期望你的“代码放松”天数尽可能地畅快。

总之，如果出于缘故，React 对我来说是不融洽的，而我想要花天数撰写标识符来赢得快感，那么最明显的做法是不要采用 React。而我绝大多数天数是不用 React 的。但，不可否认，代码是各方面的：你有标识符、钻孔、你向计算机输入的符号行，但你也有标识符结论，它的输出，你用C语言表达的想法的现实生活意义。可以从我的标识符与现实生活世界的可视化中赢得等同甚至更大的快感，我对此较为在意。

结论是，虽然有时我发现一种C语言、架构、辅助工具不好看或不好用，但我需要它来在合理的天数内让我的标识符描述现实生活的自已。也许这是大型社区紧紧围绕那些辅助工具建立小东西的其原因，或者其他许多技术优点。不管什么其原因，我的代码做为嗜好的天数极少，而且虽然我想让它变得融洽，但我也期望充分运用那些天数，这意味着采用不总是符合我的审美观标准的小东西。React 是这样的小东西。

有一天，当我思考那个话题的时候，突然想到两个难题：我能在维持高生产力的与此同时，写下既耐用又令人畅快的 React 标识符吗？我知道在其他C语言和架构中，那个难题有非常有用的标准答案。大部份那些方法单厢有相同程序的相同取舍，例如学习难度、能从 React 生态系得益的多少、紧紧围绕它的辅助工具怎样等等。大部份那些取舍都要根据工程项目的最终目标进行相同的来衡量。

我对那个难题的标准答案一般来说是许多非 React 的其他小东西。但内要一段天数，你会较为每两个取舍；你从相同的角度看待你的工程项目；你打声重新制定你设想的优点和你的需求；最后，React 会是你的标准答案。考虑到那些情况，我将原来的难题重新预设为：“在维持 React 标识符维持不变的与此同时，我还能在多某种程度上使 React 标识符更快看？”

“在维持 React 标识符维持不变的与此同时，我还能在多某种程度上使 React 标识符更快看？”

为了开始回答这难题，我建立了两个 Create React App 工程项目，采用了一些单纯的 React 标识符做为参考。我期望它有一点儿抽象化，足够单纯，这样就不会阻碍测试相同的小东西。我选择了官方的 React 讲义标识符，你可以在这里找到。

聚焦这段标识符的最单纯的 React 组件，Square 组件，我们看到如下标识符：

function Square(props) { return ( <button className=”square” onClick={props.onClick}>{props.value}</button> );}

而这是较为主观的一点：我对这段标识符很不满意。我不是在讨论这段标识符的控制技术属性。当我说它难看的时候，我只是在试图表达它在我心中唤醒的一套感觉，而这在很某种程度上是基于我对世界的总体体验，特别是编程。从那个角度来看，第两个让我抓狂的难题是 JSX。

自从 JSX 推出以来，它已经被讨论了很多，但为了阐明我的观点，我将快速说明一下。JSX 很混乱，但它也是一种现实生活产物。它源于前端控制技术的自然演变，从一开始就有某种形式的 XML 语言来定义标签。相同之处在于，JSX 一般来说位于 JavaScript 标识符中。

与口语语言进行粗略的类比，JSX 就好像某一特定语言的采用者开始采用其他语言的一整套单词和短语来表达自己。例如，当两个特定的主题是某一特定文化所固有的时候，这种情况就经常发生。当文化之外的人，说相同语言的人，面对表达关于那个主题的想法的挑战时，他们一般来说会缺乏词汇来处理那个难题，重复采用那些“产生”那个话题的人所说的语言来解决那个难题。语言纯粹主义者很快就会生气，指出你怎么能不需要外来词汇就可以说那些话题。但人们仍然会采用那些词，其中许多词最终会被纳入官方语言。JSX 诞生于 JavaScript 开发者对于表达 UI 标签的需要。

继续上面语言采用者的类比，许多灵魂将语言用于审美观目的和自我表达。诗人和文学作家一般来说是这样。他们怎样看待外语单词？好吧，他们毫无疑问会有相同的看法。他们的观点与我这里的观点类似，因为这不仅从语言表达思想的能力来看待语言，与此同时还从后现代角度考虑。从那个角度来看，JSX 的采用是不必要的：它增加了噪音，并且对于它表达思想没有帮助。

大部份那些都是说，我朝着一种更融洽的方式撰写 React 的第一步是摆脱 JSX。

无 JSX 版本的 button 组件如下所示：

const e = React.createElement;functionSquare({ onClick, value }) { return e(‘button’, { className: ‘square’, onClick }, value);}

标识符的完全一致性和简洁性带来了实质上的后现代提升。而且我们可以在无 JSX 路上走得更远。我远不是第两个讨论是否采用 JSX 的人。对于 JSX 的厌恶可能和 JSX 本身一样古老。我打赌 JSX 最初的团队至少有人说过这是不必要的。你会发现大量关于 JSX 糟糕的其原因以及不采用 JSX 的好处的阅读资料。令人高兴的是，你也可以找到控制技术上的替代品。两个突出的例子是 Hyperscript，它是 React 团队在他们的文档中推荐的。这是两个单纯的辅助工具，可以帮助你采用 JavaScript 构建超文本。它的 React 版本带来了比createElement 更吸引人的 API。我决定将它与两个称作hyperscript-helpers的小辅助工具库一起采用试试，我发现那些辅助工具对标识符耐用的贡献相当不错：

function Square({ onClick, value }) { returnbutton({ className: ‘square’, onClick },value);}

取代 JSX 是帕累托原则在 React 标识符耐用方面的应用。省力，效果好。如果想要更漂亮的 React 标识符，每个人都应该采取行动。继续探索怎样在架构领域美化 React 标识符，我发现了两个死胡同。虽然我可以探索许多设计模式和单纯的惯例，但它们需要根据具体情况评估它们的控制技术含义，而我正在寻找更通用的方法。因此，下一步需要在 JavaScript 层探索。

JavaScript 是一种非常灵活的语言，这是一把双刃剑。这也可以从后现代角度来探索。有许多相同的方法可以撰写有效的标识符，但会有明显的风格差异和控制技术意义。许多辅助工具可以帮助你自定义和强制你所选择风格，在那些辅助工具中，我最喜欢：StandardJS。StandardJS 是两个用于自动将一系列合理的代码样式选择应用到你的标识符的两个辅助工具。在那些选择中最具有后现代意义的一点是去掉了分号。

我发现，分号在 JS 标识符中是一种不必要的噪音，我很乐意冒险不采用它们。在我将 StandardJS 合并到我的参考示例后，是下面这样：

function Square ({ onClick, value }) { return button({ className: ‘square’, onClick }, value)}

现在就 JavaScript 标识符而言，这是我所能得到的最好的标识符了。回顾到目前为止我所做的小东西，一切看起来还都不错。那些更改实现很单纯，可以很容易地集成到我的默认本业工程项目的 React 配置中。另一方面，这在后现代上与我在其他相同语言中的体验仍然相去甚远。我已经讨论过其他语言的情况，重点是我想在 JS 世界中采用 React。除非有什么小东西能给 JavaScript 增添许多优雅的光彩，与此同时又维持 JavaScript 的模样，否则极难达到我预设的界限。

“就像 JavaScript 一样。”当试图发挥我的创造力去寻找相同的可能性时，这句话让我回到了十年前。我正在学习 Web 开发，而且刚刚碰到 Ruby on Rails。那时，Rails 在发布时一般来说会内置附带一种相同类型的 JavaScript，称作 CoffeeScript。CoffeeScript 有一条黄金法则：“这只是 JavaScript。”是那样，CoffeeScript 可以满足我的标准，因此我决定看看那个工程项目进展怎样并尝试一下。

我知道，自从 ES5 以来，CoffeeScript 的许多好的优点被整合到 JS 标准中，因此从控制技术上讲，人们采用 CoffeeScript 的理由更少了。随着编译器的出现，使得每个人都可以采用甚至还不是标准的 JS 优点，即使是不得不支持旧浏览器的开发者现在也可以从最新的语言优点中受益。这使得 CoffeeScript 的流行程度大不如前。但我的兴趣不是控制技术性的。我想找到两个令人愉快的后现代方案，使得我可以撰写看起来不错的 React 标识符，与此同时还是 JavaScript，而不需要学习一种新语言或者架构。

从文档来看，CoffeeScript 与 JavaScript 非常接近，我可以忽略学习曲线，而且它在后现代方面给标识符带来了显著改进。我一直怀疑它是否还在维护，事实证明它确实还在维护。其最新版本在今年初完成。它的最新主版本包含了新的 JS 优点，甚至支持 JSX。因此，我决定将它集成到我的示例工程项目中。为此，我不得不将我的 Creact React App 配置弹出，这样我就可以为 CoffeeScript 增加两个 Webpack 加载器。除此之外，转换非常单纯。

这是设计的 Button 组件最终标识符的模样：

Square = ({ onClick, value }) -> button ‘.square’, { onClick }, value

如果你对整个标识符最终的模样感到好奇，你可以在这里找到它。

在后现代方面，我认为那个标识符对于我最初的标识符是巨大的进步。语法简洁，看起来干净。

关于美的追求，更少是更美，人们已经说了很多。我很认同这一点。结论发现，我的耐用探索基本上是用更少的 React 标识符表达思想。CoffeeScript 带来的卓越改进——也是其他语言采用的方式——是去掉无意义的标记。这种认识在最后会很明显，但最初不怎么明显。它的目的是总体上增强 less 的力量。

从务实的角度来看，乍一看，采用这种风格似乎不会影响生产力。CoffeeScript 推出已经有一段天数了，而且我期望它有许多像样的辅助工具。我在做那个快速实验时没有感到意外。不过，有一件事让我无法完全采用它：那是与 TypeScript 一起采用的能力。我知道怎样让它起效，但我决定在这一点上停止探索。不管怎样，如果你喜欢那个情景，就会有兴趣采用相似的方案，并且会对它怎样与 TypeScript 一起工作感到好奇，可以留言告诉我。

感谢您的阅读。

总结： 从标识符后现代的角度来看，Hyperscript 和 CoffeeScript 的结合是撰写漂亮的 React 标识符的一种很好的方式。

作者介绍

Vinicius Andrade，学会代码，学会思考，学会行动，学会等待——在 https://vicnicius.com 记录所思所感。

原文链接：

https://medium.com/javascript-in-plain-english/writing-beautiful-react-code-using-a-good-old-mate-ca1450c0dc06

延伸阅读：