In React 16.2, improved support for Fragments has been added. More information can be found on React's blog post here.
We are all familiar with the following code:
render() {
return (
// Extraneous div element :(
<div>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</div>
);
}
Yes, we need a container div, but it's not that big of a deal.
In React 16.2, we can do this to avoid the surrounding container div:
render() {
return (
<Fragment>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</Fragment>
);
}
In either case, we still need need a container element surround the inner elements.
My question is, why is using a Fragment preferable? Does it help with performance? If so, why? Would love some insight.
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.
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.
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
Adding to all answers above there is one more advantage: code readability, Fragment component supports a syntactic sugar form, <>. Thus the code in your question can be written more easily as:
render() {
return (
<>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</>
);
}
According to docs,
In React, this desugars to a <React.Fragment/> element, as in the example from the previous section. (Non-React frameworks that use JSX may compile to something different.)
Clutter-free, right ?
Note that you still need to use <Fragment> syntax if you need to provide key to the fragment.
Added features not possible before with JSX
Better semantic jsx markup. Wrapper elements are used when needed not because they are forced to.
Less overall dom markup (increased render performance and less memory overhead)
It as simple as when you don't need a wrapper element you aren't forced to use one. Having less elements is great but I think the biggest benefit is being able to render elements in jsx that weren't previously possible and adding better semantic meaning to wrapper elements because they are optional now.
This wasn't possible before:
<select>
{this.renderOptions()}
</select>
Glancing at the following in React 15 you can't tell if the wrapper element is needed or not:
<span>
<h1>Hello</h1>
{this.getContent()}
</span>
As per the reactjs.org docs most important needs of <Fragment> </Fragment> instead of div's are to avoid breaking HTML semantics. When we use div's instead of <Fragment> </Fragment> we break the HTML semantics.
To know more about html semantics. please click
and also there are cases where if you use div's instead of Fragments it will be invalid html, for example look at this code:
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>
Fragments solve this problem.
When working with React, there are cases where you will need to render multiple elements or return a group of related items. Here’s an example:
function App() {
return (
<h1>Hello React!</h1>
<h1>Hello React Again!</h1>
);
}
If you try to run your app with the code above, you will run into an error stating that Adjacent JSX elements must be wrapped in an enclosing tag. This implies that you need to wrap both elements within a parent div.
function App() {
return (
<div>
<h1>Hello React!</h1>
<h1>Hello React Again!</h1>
</div>
);
}
Doing this will fix the error, but it comes with a degree of risk. You are adding an extra node to the DOM, which is not necessary. In a case like this, where the above is a child component that will be enclosed within a parent component, this becomes a problem.
function Table() {
return (
<table>
<td>This is a Table Component</td>
<Columns />
</table>
);
}
function Columns() {
return (
<div>
<td>Hello React!</td>
<td>Hello React Again!</td>
</div>
);
}
The resulting HTML for the Table component will be invalid because of the additional div that was added.
function Table() {
return (
<table>
<td>This is a Table Component</td>
<div>
<td>Hello React!</td>
<td>Hello React Again!</td>
</div>
</table>
);
}
Let’s take a look at a better way of solving this by using React Fragment, which will not add any additional node to the DOM. The syntax looks like this:
function Columns() {
return (
<React.Fragment>
<td>Hello React!</td>
<td>Hello React Again!</td>
</React.Fragment>
);
}
You can also use the short syntax <></> for declaring a Fragment.
function Columns() {
return (
<>
<td>Hello React!</td>
<td>Hello React Again!</td>
</>
);
}
Using <React.Fragment>...</React.Fragment>, we can add a parent tag to our JSX elements without adding an extra node to the DOM.
you can replace the extra div tags with React.Fragment
writing React.Fragment every time is too long for you. React.Fragment has a shorthand syntax that you can use. It is <>...</>.
When you want to group components but don't want a div tag HTML in the generated HTML, you can use fragment. The generated HTML for <> <p> Hello </p> </> is just this: <p> Hello </p>
If we'd have used div container, the <div>…</div> will be generated too!
Related
I was reading the React doc and get confused by the topic Fragments.
Since we can basically return an array in React, in what situation would one need <Fragements />?
Here is a code sample:
const ReturnArray = () => {
const items = [
<div key={1}>Item 1</div>,
<div key={2}>Item 2</div>,
<div key={3}>Item 3</div>,
]
return items
}
const ReturnFragments = () => {
const items =
<React.Fragment>
<div key={1}>Item 1</div>
<div key={2}>Item 2</div>
<div key={3}>Item 3</div>
</React.Fragment>
return items
}
I think they are the same.
Most existing topics talk about "key warning issues" like this on github, but I just want to know the use cases of <Fragments />
Edit:
Please tell me if there is anything ambiguous.
To be specific:
Please explain the difference between <ReturnArray /> and <ReturnFragments />. They both return multiple elements without useless <div> tag. Why bother using the extra <React.Fragment /> part?
Official document says
Using array notation has has some confusing differences from normal
JSX:
Children in an array must be separated by commas.
Children in an array must have a key to prevent React’s key warning.
Strings must be wrapped in quotes.
So to make it simple, React provides Fragment component that can be used in place of arrays.
Consider how we can wrap multiple children using array
render() {
return [
"Some text.",
<h2 key="heading-1">A heading</h2>,
"More text.",
<h2 key="heading-2">Another heading</h2>,
"Even more text."
];
}
And how it can be achieved using Fragments.
render() {
return (
<Fragment>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</Fragment>
);
}
Taken directly from official document.
Fragments can be written as below aswell.
render() {
return (
<>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</>
);
}
There are two major advantages of using Fragments over array in return statement
Simplistic syntax similar to Other components so that you don't have to worry about return comma separated values, wrapping strings in quotes etc
Fragments can take attribute such as key which is often important when you are returning data from within map. You can't do that using an array.
Example
const ReturnFragments = () => {
const items = list.map((item) => {
<React.Fragment key={item.id}>
<div key={1}>Item 1</div>
<div key={2}>Item 2</div>
<div key={3}>Item 3</div>
</React.Fragment>
})
return items
}
Fragments and arrays are intended to address different use cases and behave differently in one important way.
Fragments will not warn if you omit a key property, while arrays will.
If your component returns several static children, return a fragment.
<Fragment>
<li>One advantage of our product is lorem</li>
<li>Another is ipsum!</li>
</Fragment>
If your component returns dynamically generated children, return an array.
items.map(item => <li key={item}>{item}</li>);
I am paraphrasing the maintainers' responses to an issue I opened in the React repo about a similar question. I highly recommend reading it for more detail: https://github.com/facebook/react/issues/12776
When you create a new component, the render method needs to return one and only one element so usually it's a wrapper of many elements, instead of creating a useless div to the dom, you can use the fragment component.
Quote from React Fragments docs :
A common pattern in React is for a component to return multiple elements. Fragments let you group a list of children without adding extra nodes to the DOM.
Without Fragments
render() {
return {
<div> ---> Useless root
<div>fake</div>
<div>fake</div>
<div>fake</div>
</div>
}
}
With Fragments
render() {
return {
<React.Fragment> ----> Not rendered to the DOM
<div>fake</div>
<div>fake</div>
<div>fake</div>
</React.Fragment>
}
}
I was reading the React doc and get confused by the topic Fragments.
Since we can basically return an array in React, in what situation would one need <Fragements />?
Here is a code sample:
const ReturnArray = () => {
const items = [
<div key={1}>Item 1</div>,
<div key={2}>Item 2</div>,
<div key={3}>Item 3</div>,
]
return items
}
const ReturnFragments = () => {
const items =
<React.Fragment>
<div key={1}>Item 1</div>
<div key={2}>Item 2</div>
<div key={3}>Item 3</div>
</React.Fragment>
return items
}
I think they are the same.
Most existing topics talk about "key warning issues" like this on github, but I just want to know the use cases of <Fragments />
Edit:
Please tell me if there is anything ambiguous.
To be specific:
Please explain the difference between <ReturnArray /> and <ReturnFragments />. They both return multiple elements without useless <div> tag. Why bother using the extra <React.Fragment /> part?
Official document says
Using array notation has has some confusing differences from normal
JSX:
Children in an array must be separated by commas.
Children in an array must have a key to prevent React’s key warning.
Strings must be wrapped in quotes.
So to make it simple, React provides Fragment component that can be used in place of arrays.
Consider how we can wrap multiple children using array
render() {
return [
"Some text.",
<h2 key="heading-1">A heading</h2>,
"More text.",
<h2 key="heading-2">Another heading</h2>,
"Even more text."
];
}
And how it can be achieved using Fragments.
render() {
return (
<Fragment>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</Fragment>
);
}
Taken directly from official document.
Fragments can be written as below aswell.
render() {
return (
<>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</>
);
}
There are two major advantages of using Fragments over array in return statement
Simplistic syntax similar to Other components so that you don't have to worry about return comma separated values, wrapping strings in quotes etc
Fragments can take attribute such as key which is often important when you are returning data from within map. You can't do that using an array.
Example
const ReturnFragments = () => {
const items = list.map((item) => {
<React.Fragment key={item.id}>
<div key={1}>Item 1</div>
<div key={2}>Item 2</div>
<div key={3}>Item 3</div>
</React.Fragment>
})
return items
}
Fragments and arrays are intended to address different use cases and behave differently in one important way.
Fragments will not warn if you omit a key property, while arrays will.
If your component returns several static children, return a fragment.
<Fragment>
<li>One advantage of our product is lorem</li>
<li>Another is ipsum!</li>
</Fragment>
If your component returns dynamically generated children, return an array.
items.map(item => <li key={item}>{item}</li>);
I am paraphrasing the maintainers' responses to an issue I opened in the React repo about a similar question. I highly recommend reading it for more detail: https://github.com/facebook/react/issues/12776
When you create a new component, the render method needs to return one and only one element so usually it's a wrapper of many elements, instead of creating a useless div to the dom, you can use the fragment component.
Quote from React Fragments docs :
A common pattern in React is for a component to return multiple elements. Fragments let you group a list of children without adding extra nodes to the DOM.
Without Fragments
render() {
return {
<div> ---> Useless root
<div>fake</div>
<div>fake</div>
<div>fake</div>
</div>
}
}
With Fragments
render() {
return {
<React.Fragment> ----> Not rendered to the DOM
<div>fake</div>
<div>fake</div>
<div>fake</div>
</React.Fragment>
}
}
it can only return only one element tag in render.
In v16, we can render multiple elements by using an array.
so why cannot straightly write mutiple element tags in React?
render(){
return(
<div />
<div />
)
}
I mean that why cannot render multiple elements but not how to render mutiple elements.
React implementation relies on constructing a tree like structure which it uses to for reconcilation. When you return multiple elements from React elements from the render method, the assumtion that the tree will have one root node for the Component will not longer hold, hence making it difficult to process reconcilation algorithm.
Thus react gives you a limitation to provide a root node. If you return an array of elements from v16 onwards, react will internally create a dummy node as the parent.
From version 16.2 onwards React provides a React.Fragment component, that provides a cleaner syntax to return multiple elements
render(){
return(
<React.Fragment>
<div />
<div />
</React.Fragment>
)
}
React needs a parent element to render anything. You could put them in an array, or use a tool they gave for this exact purpose, the fragment component.
A fragment is just an empty node that won't show in the DOM allowing you to return multiple JSX components next to each other :
render(){
return(
<>
<div />
<div />
</>
)
}
If your linter is not a fan of this, you can use React.Fragment instead :
render(){
return(
<React.Fragment>
<div />
<div />
</React.Fragment>
)
}
The short answer to your question is... well this is just how React works and how their rendering engine is designed.
For now, multiple elements put together will not be interpreted as an array.
You can try
render(){
return[
<div> Div 1</div>,
<div> Div 2</div>,
<div> Div 3</div>,
<div> Div 4</div>
]
}
Sometimes you might need to render web-components from your react app.
Web-components often use a special <template> ... </template> tag.
But if I try to render such markup with react like this:
render() {
return (
<template>
<div>some content</div>
</template>
)
}
then my web-components don't work correctly.
The reason is that JSX does a different job than what the <template /> tags exists for. The idea of a template tag is to not render its children and pretty much handle it like unparsed text (the browser actually parses it just to make sure its valid html, but does nothing more)
But when you write this in JSX:
return (
<template>
<div>some content</div>
</template>
)
you're basically instructing react to create a 'template' element and then create a 'div' element and then to append this div to the template as a child.
So under hood this happens:
const template = document.createElement('template')
const div = document.createElement('div')
const text = document.createTextNode('some text')
div.appendChild(text)
template.appendChild(div)
But what you want is to set the contents of the <template /> as a string. You can use innerHTML for that.
Solution
One solution would be:
render() {
return (
<template
dangerouslySetInnerHTML={{
__html: '<div>some content</div>'
}}
/>
)
}
Now you're asking react to create all those children tags as node elements but letting the browser decide what to do with them.
Nicer solution
You might not want to use dangerouslySetInnerHTML all the time. So let's create a helper component:
function Template({ children, ...attrs }) {
return (
<template
{...attrs}
dangerouslySetInnerHTML={{ __html: children }}
/>
);
}
Now any time you need to use a template you can use it like this:
render() {
return (
<Template>
{'<div>some content</div>'}
</Template>
)
}
Don't forget to put the inner content in quotes, because it should be a string.
I know that this question has already an answer, but there is another, I guess simpler solution to do that creating hoc (Higher Order Component).
Just create new "component" like this:
// hoc/Template.js
const template = props => props.children
export default template
and then you can use it in your project this way:
import './hoc/Template.js'
...
render() {
return (
<Template>
{'<div>some content</div>'}
</Template>
)
}
Newer version of react has already build it such a component, so you can achieve same thing without creating component.
import { Fragment } from 'react'
...
render() {
return (
<Fragment>
{'<div>some content</div>'}
</Fragment>
)
}
This is actually a bug in React! https://github.com/facebook/react/issues/19932
When the native browser parses the <template> tag, it appends all children to the template's content fragment, instead of adding them as children. So a template should never actually have any children.
However, if you programmatically build the DOM (the way react-dom does), then the template will have an empty content fragment, since all children are added as children. This is why web components will not behave properly with these templates.
Here's an example of the problem too: https://codesandbox.io/s/new-sun-8l62o?file=/src/App.tsx:1056-1118
The easiest workaround is to use dangerouslySetInnerHTML, like so:
<template dangerouslySetInnerHTML={{ __html: `
<p> Some text </p>
` }} />
This is limited by the fact that you can only supply raw HTML (no custom React elements). However, since you're using the <template> tag in the first place, it seems highly unlikely that you'd also be using React within the template.
I am still a noob at React and in many examples on the internet, I see this variation in rendering child elements which I find confusing. Normally I see this:
class Users extends React.Component {
render() {
return (
<div>
<h2>Users</h2>
{this.props.children}
</div>
)
}
}
But then I see an example like this:
<ReactCSSTransitionGroup
component="div"
transitionName="example"
transitionEnterTimeout={500}
transitionLeaveTimeout={500}
>
{React.cloneElement(this.props.children, {
key: this.props.location.pathname
})}
</ReactCSSTransitionGroup>
Now I understand the api but the docs don't exactly make clear when I should be using it.
So what does one do which the other can't? Could someone explain this to me with better examples?
props.children isn't the actual children; It is the descriptor of the children. So you don't have actually anything to change; you can't change any props, or edit any functionality; you can only read from it. If you need to make any modifications you have to create new elements using React.CloneElement.
https://egghead.io/lessons/react-use-react-cloneelement-to-extend-functionality-of-children-components
An example:
main render function of a component such as App.js:
render() {
return(
<Paragraph>
<Sentence>First</Sentence>
<Sentence>Second</Sentence>
<Sentence>Third</Sentence>
</Paragraph>
)
}
now let's say you need to add an onClick to each child of Paragraph; so in your Paragraph.js you can do:
render() {
return (
<div>
{React.Children.map(this.props.children, child => {
return React.cloneElement(child, {
onClick: this.props.onClick })
})}
</div>
)
}
then simply you can do this:
render() {
return(
<Paragraph onClick={this.onClick}>
<Sentence>First</Sentence>
<Sentence>Second</Sentence>
<Sentence>Third</Sentence>
</Paragraph>
)
}
Note: the React.Children.map function will only see the top level elements, it does not see any of the things that those elements render; meaning that you are providing the direct props to children (here the <Sentence /> elements). If you need the props to be passed down further, let's say you will have a <div></div> inside one of the <Sentence /> elements that wants to use the onClick prop then in that case you can use the Context API to do it. Make the Paragraph the provider and the Sentence elements as consumer.
Edit:
Look at Vennesa's answer instead, which is a better explanation.
Original:
First of all, the React.cloneElement example only works if your child is a single React element.
For almost everything {this.props.children} is the one you want.
Cloning is useful in some more advanced scenarios, where a parent sends in an element and the child component needs to change some props on that element or add things like ref for accessing the actual DOM element.
In the example above, the parent which gives the child does not know about the key requirement for the component, therefore it creates a copy of the element it is given and adds a key based on some unique identifier in the object. For more info on what key does: https://facebook.github.io/react/docs/multiple-components.html
In fact, React.cloneElement is not strictly associated with this.props.children.
It's useful whenever you need to clone react elements(PropTypes.element) to add/override props, without wanting the parent to have knowledge about those component internals(e.g, attaching event handlers or assigning key/ref attributes).
Also react elements are immutable.
React.cloneElement( element, [props], [...children] ) is almost equivalent to:
<element.type {...element.props} {...props}>{children}</element.type>
However, the children prop in React is especially used for containment (aka composition), pairing with React.Children API and React.cloneElement, component that uses props.children can handle more logic(e.g., state transitions, events, DOM measurements etc) internally while yielding the rendering part to wherever it's used, React Router <switch/> or compound component <select/> are some great examples.
One last thing that worth mentioning is that react elements are not restricted to props.children.
function SplitPane(props) {
return (
<div className="SplitPane">
<div className="SplitPane-left">
{props.left}
</div>
<div className="SplitPane-right">
{props.right}
</div>
</div>
);
}
function App() {
return (
<SplitPane
left={
<Contacts />
}
right={
<Chat />
} />
);
}
They can be whatever props that makes sense, the key was to define a good contract for the component, so that the consumers of it can be decoupled from the underlying implementation details, regardless whether it's using React.Children, React.cloneElement, or even React.createContext.