为什么React 16中的片段比容器div更好?

在React 16.2中,增加了对的支持Fragments更多信息可以在React的博客文章中找到。

我们都熟悉以下代码:

render() {
  return (
    // Extraneous div element :(
    <div>
      Some text.
      <h2>A heading</h2>
      More text.
      <h2>Another heading</h2>
      Even more text.
    </div>
  );
}

是的,我们需要一个容器div,但这没什么大不了的。

在React 16.2中,我们可以这样做以避免周围的容器div:

render() {
  return (
    <Fragment>
      Some text.
      <h2>A heading</h2>
      More text.
      <h2>Another heading</h2>
      Even more text.
    </Fragment>
  );
}

无论哪种情况,我们仍然需要围绕内部元素的容器元素。

我的问题是,为什么使用Fragment首选?它对性能有帮助吗?如果是这样,为什么?希望有一些见识。

L十三2020/03/11 12:22:38
  1. 使用<React.Fragment>...</React.Fragment>,我们可以向JSX元素添加一个父标记,而无需向DOM添加额外的节点。
  2. 您可以用React.Fragment替换多余的div标签
  3. 每次都写React.Fragment对您来说太长了。React.Fragment具有可以使用的速记语法。它是<>...</>.
TomTony2020/03/11 12:22:38

除了上述所有答案之外,还有一个优点:代码可读性强Fragment组件支持语法糖形式,<>因此,您问题中的代码可以更容易地编写为:

render() {
  return (
    <>
      Some text.
      <h2>A heading</h2>
      More text.
      <h2>Another heading</h2>
      Even more text.
    </>
  );
}

根据文档

在React中,这变成了<React.Fragment/>元素,如上一节中的示例所示。(使用JSX的非反应框架可能会编译成其他东西。)

整洁,对吗?

请注意,<Fragment>如果需要提供key给片段,您仍然需要使用语法

泡芙蛋蛋2020/03/11 12:22:38

根据reactjs.org 文档,最重要的需求<Fragment> </Fragment>是避免破坏HTML语义而不是div。当我们使用div而不是<Fragment> </Fragment>HTML语义时。

要了解有关html语义的更多信息。单击 ,并且在某些情况下,如果您使用div而不是Fragments,它将是无效的html,例如,看下面的代码:

class Columns extends React.Component {
  render() {
    return (
      <div>
        <td>Hello</td>
        <td>World</td>
      </div>
    );
  }
}

<table>
      <tr>
        <div>
          <td>Hello</td>
          <td>World</td>
        </div>
      </tr>
 </table>

碎片解决了这个问题。

达蒙乐2020/03/11 12:22:38
  • JSX之前无法提供的新增功能
  • 更好的语义jsx标记。包装器元素在不需要时使用,而不是因为被迫使用。
  • 总体dom标记更少(提高了渲染性能并减少了内存开销)

就像不需要包装元素一样简单,您也不必使用一个包装元素。拥有更少的元素是很棒的,但是我认为最大的好处是能够在jsx中呈现以前不可能的元素,并为包装器元素添加更好的语义,因为它们现在是可选的。

在此之前这是不可能的:

 <select>
    {this.renderOptions()}
 </select>

在React 15中浏览以下内容,您无法确定是否需要wrapper元素:

<span>
  <h1>Hello</h1>
  {this.getContent()}
</span>
阿飞Harry小胖2020/03/11 12:22:38
  1. It’s a tiny bit faster and has less memory usage (no need to create an extra DOM node). This only has a real benefit on very large and/or deep trees, but application performance often suffers from death by a thousand cuts. This is one cut less.
  2. Some CSS mechanisms like Flexbox and CSS Grid have a special parent-child relationship, and adding divs in the middle makes it hard to keep the desired layout while extracting logical components.
  3. The DOM inspector is less cluttered. :-)

You can find the descriptions of some other use cases in this React issue: Add fragment API to allow returning multiple components from render