react jsx_React的JSX：硬币的另一面

react jsx

Stay calm. Embrace the evolution.

保持冷静。 拥抱进化。

When React was released, many people took one look at JSX and lost their minds. What are these angle brackets doing in JavaScript?! What about separation of concerns? Has Facebook learned nothing from the community?

当React发布时，许多人对JSX一无所知。 这些尖括号在JavaScript中做什么？ 那么分离关注点呢？ Facebook没有从社区中学到任何东西吗？

Like many, my initial reaction to React’s JSX was skeptical, to say the least. And while I’ve come to love JSX, anytime I introduce it to a new developer, I feel like I’m showing off my ugly baby.

至少可以说，和许多人一样，我对React的JSX的最初React是持怀疑态度的。 当我开始喜欢JSX时，无论何时将它介绍给新的开发人员，我都感觉自己在炫耀我丑陋的孩子。

Despite the initial drama, I’ve come to realize that JSX isn’t such a radical idea after all. In fact, it’s simply the other side of the coin. It’s a natural evolutionary transition. To appreciate why, a history lesson is in order.

尽管最初有戏剧性，但我已经意识到JSX毕竟不是一个激进的想法。 实际上，它只是硬币的另一面 。 这是自然的进化过渡。 要理解为什么，历史课是适当的。

阶段1：不干扰JavaScript (Phase 1: Unobtrusive JavaScript)

Remember the good old days of jQuery? The era of unobtrusive JavaScript was in full bloom. Our HTML was pure HTML. Our JavaScript was pure JavaScript. Our concerns were perfectly separated.

还记得jQuery的美好时光吗？ 不打扰JavaScript时代正盛开。 我们HTML是纯HTML。 我们JavaScript是纯JavaScript。 我们的关注完全分开了。

We’d write HTML like this:

我们将这样编写HTML：

<a class=”hide”>Click to hide me</a>

Then we’d write JavaScript like this:

然后，我们将这样编写JavaScript：

$(‘.hide’).click(function() { $(this).hide(); }

#win. Right? Not exactly.

＃赢得。 对？ 不完全是。

This seemed like a great idea. Our HTML is totally pure! But then we realized some problems: Uh, how can I tell that these two lines are interconnected? Answer: I can’t unless I read every single line of JavaScript. With this pattern, you can’t change a line of markup without checking every single line of JavaScript to assure you’re not breaking a selector. You see, there’s no actual separation going on here. Sure, the JS and HTML are in separate files, but these two technologies are fundamentally joined at the hip. They must move in lockstep or the application will crash.

这似乎是个好主意。 我们HTML完全是纯文本！ 但是后来我们意识到了一些问题：呃，我怎么能知道这两条线是互连的？ 答：除非我阅读了每一行JavaScript，否则我不会。 使用这种模式， 如果不检查JavaScript的每一行以确保不破坏选择器 ， 就无法更改标记行。 您会看到，这里没有实际分离。 当然，JS和HTML位于单独的文件中，但是这两种技术在本质上是紧密结合在一起的。 它们必须同步移动，否则应用程序将崩溃。

Strictly separating HTML and JS actually led to applications that were harder to maintain and debug. Each time you wanted to change a line of markup, you had to worry about breaking a jQuery selector. Perhaps if we relaxed our religious devotion to separation of concerns, we could relieve some of this pain? This ushered in phase 2…

严格地将HTML和JS分开实际上导致了难以维护和调试的应用程序。 每次您想更改标记行时，都必须担心破坏jQuery选择器。 也许，如果我们放宽对关注分离的虔诚奉献精神，就可以减轻这种痛苦？ 这迎来了第二阶段…

阶段2：双向装订 (Phase 2: Two-way Binding)

When front-end developers saw two-way binding in Knockout and Angular, it was a revelation. Many of us tossed our religious devotion to separation of concerns and embraced the power of declaring bindings in HTML. When data changed, the UI changed. When the UI changed, the data changed. So clean. So simple.

当前端开发人员在Knockout和Angular中看到双向绑定时，这是一个启示。 我们中的许多人抛弃了对分离关注点的虔诚奉献精神，并接受了在HTML中声明绑定的功能。 数据更改时，UI也更改。 UI更改后，数据也更改了。 好干净 很简单。

Sure, every library and framework has a proprietary way of getting this done, but they’re all fundamentally doing the same thing. Just consider this simple example of iterating over an array in a few popular frameworks:

当然，每个库和框架都有专有的方法来完成此任务，但是从根本上说，它们都在做同一件事。 只需考虑以下在几个流行框架中遍历数组的简单示例：

//Angular
<div ng-repeat=”user in users”>
    
//Ember
{{#each user in users}}
 
//Knockout
data-bind=”foreach: users”

But something interesting is at play here. Few have recognized a very fundamental problem: We’re effectively putting JavaScript in our HTML. This isn’t separation of concerns. All of these approaches do the same thing: They make HTML more powerful by adding extra proprietary markup. This markup is effectively parsed as JavaScript. And now that we’re finally comfortable intermingling JS and HTML this way, it’s time for React to step in and show us the other side of the coin…

但是，这里有一些有趣的事情。 很少有人意识到一个非常根本的问题： 我们正在将JavaScript有效地放入HTML中。 这不是关注点分离。 所有这些方法都做同样的事情：通过添加额外的专有标记，它们使HTML更加强大。 该标记被有效地解析为JavaScript。 现在我们终于可以通过这种方式将JS和HTML混合在一起了，是时候让React介入并向我们展示硬币的另一面了……

阶段3：JSX (Phase 3: JSX)

React’s JSX isn’t a radical shift. It’s merely the fruit of a simple realization:

React的JSX并不是一个根本性的转变。 这仅仅是一个简单实现的结果：

As an industry, we’ve already decided: HTML and JavaScript belong together.

作为一个行业，我们已经决定：HTML和JavaScript在一起。

Admittedly, we didn’t say this out loud. But embracing Angular, Knockout and Ember made our new preference clear. As I established above, writing data-binding code in HTML is effectively putting JS in HTML. But if we’re going to intermingle, why should we choose to augment a technology as weak and lax as HTML? Browsers have loosely interpreted HTML since the beginning of time. So is HTML a logical foundation for declaring data-binding, looping, and conditional logic?

诚然，我们没有大声说出来。 但是，采用Angular，Knockout和Ember可以使我们的新偏好更加明确。 如上所述，用HTML编写数据绑定代码实际上是将JS放入HTML。 但是， 如果我们要混合在一起，为什么我们应该选择增加像HTML这样薄弱的技术呢？ 自从开始以来，浏览器就松散地解释了HTML。 那么HTML是声明数据绑定，循环和条件逻辑的逻辑基础吗？

Facebook recognized that JavaScript was a more logical and powerful technology for handling these two intermingled concerns. The epiphany comes down to this:

Facebook认识到JavaScript是处理这两个混杂问题的更合乎逻辑且功能更强大的技术。 顿悟可以归结为：

Angular, Ember and Knockout put “JS” in your HTML.

Angular，Ember和Knockout在您HTML中添加了“ JS”。

The benefits of this move are multifaceted and not necessarily appreciated until you’ve tried working with React and JSX. React’s JSX is fundamentally superior to all the “Phase 2” style frameworks above for a few simple reasons:

在您尝试使用React和JSX之前，此举的好处是多方面的，不一定得到赞赏。 由于一些简单的原因，React的JSX从根本上优于上述所有“阶段2”样式框架：

编译时错误 (Compile-time Errors)

When you make a typo in HTML, you generally have no idea where you screwed up. In many cases it’s a silent run-time error. For example, if you type n-repeat instead of ng-repeat when working with Angular, nothing will happen. Same story with data-bnd vs data-bind in Knockout. In either case, your app will silently fail at runtime. That’s frustrating.

当您用HTML打字时，您通常不知道在哪里弄错了。 在许多情况下，这是一个无提示的运行时错误。 例如，如果在使用Angular时键入n-repeat而不是ng-repeat，则不会发生任何事情。 在淘汰赛中，数据绑定与数据绑定的故事相同。 无论哪种情况，您的应用程序都将在运行时静默失败。 真令人沮丧。

In contrast, when you make a typo in JSX, it won’t compile. Forgot to close that <li> tag? Wouldn’t you love to get rich feedback like this when you make a typo in your HTML?

相反，当您在JSX中输入错误时，它将无法编译。 忘记关闭那个<li>标签了吗？ 当您在HTML中打错字时，您是否不希望获得如此丰富的反馈？

ReactifyError: /components/header.js: Parse Error: Line 23: Expected corresponding JSX closing tag for li while parsing file: /components/header.js

With JSX, this detailed feedback is finally a reality! It’s hard to overemphasize what a big win this is. This rapid feedback loop greatly increases productivity. As I discuss in my Clean Code course, well- engineered solutions fail fast.

有了JSX，这种详细的反馈终于成为现实！ 很难过分强调这是多么大的胜利。 这种快速的反馈循环大大提高了生产率。 正如我在“清洁代码”课程中讨论的那样， 精心设计的解决方案很快就会失败 。

利用JavaScript的全部功能 (Leverage the Full Power of JavaScript)

Composing your markup within JavaScript means you can enjoy all the power of JavaScript when working with your markup, instead of a small proprietary subset that is offered within HTML-centric frameworks like Angular and Knockout.

在JavaScript中组合标记意味着您可以在使用标记时享受JavaScript的所有功能，而不是像Angular和Knockout这样的以HTML为中心的框架中提供的小型专有子集。

Client-side frameworks shouldn’t require you to learn a proprietary syntax for declaring loops and conditionals.

客户端框架不应该要求您学习专有的语法来声明循环和条件。

React avoids the overhead of learning yet another proprietary way to declare looping and basic conditional logic. As you can see above in the Phase 2 section, every two-way binding framework utilizes its own special syntax. In contrast, JSX looks nearly identical to HTML, and it uses plain ‘ol JavaScript for things like conditionals and loops. In an ecosystem as fragmented as JavaScript, not having to learn yet another proprietary data binding syntax is a nice win.

React避免了学习另一种专有的声明循环和基本条件逻辑的专有方法的开销。 如您在上面的“阶段2”部分中所见，每个双向绑定框架都使用自己的特殊语法。 相反，JSX看起来几乎与HTML相同，并且它对条件和循环之类的内容使用普通的'ol JavaScript。 在像JavaScript这样零散的生态系统中，不必学习另一种专有数据绑定语法是一个不错的选择。

And since you’re writing your markup in the same file as the associated JavaScript data, many IDE’s will give you intellisense support as you reference your functions. Think about how often you’ve made a typo when referencing a function in HTML-oriented frameworks.

而且由于您将标记和关联JavaScript数据写入同一文件中，因此在引用函数时，许多IDE都将为您提供智能感知支持。 想一想在面向HTML的框架中引用函数时您经常打错字。

最后的想法 (Final Thoughts)

JSX isn’t some wild idea. It’s a natural progression. So try not to freak out.

JSX不是一个疯狂的想法。 这是自然的进步。 因此，请不要惊慌。

JSX isn’t revolutionary. It’s evolutionary.

JSX不是革命性的。 它是进化的。

Like most forms of evolution, it’s a clear improvement.

像大多数形式的进化一样，它是明显的改进。

Want to learn more? Check out my new course “Building Applications with React and Flux” on Pluralsight.

想了解更多？ 在Pluralsight上查看我的新课程“ 使用React和Flux构建应用程序 ”。

Chime in on Reddit or Hacker News.

订阅Reddit或Hacker News 。

Cory House is the author of “Building Applications with React and Flux”, “Clean Code: Writing Code for Humans” and multiple other courses on Pluralsight. He is a Software Architect at VinSolutions and trains software developers internationally on software practices like front-end development and clean coding. Cory is a Microsoft MVP, Telerik Developer Expert, and founder of outlierdeveloper.com.

Cory House是“ 使用React和Flux构建应用程序 ”，“ 纯净代码：为人类编写代码 ”以及其他有关Pluralsight的课程的作者。 他是VinSolutions的软件架构师，并就前端开发和干净编码等软件实践对国际软件开发人员进行培训 。 Cory是Microsoft MVP，Telerik开发专家和outlierdeveloper.com的创始人。

翻译自: https://www.freecodecamp.org/news/react-s-jsx-the-other-side-of-the-coin-2ace7ab62b98/

react jsx