With React 17, you no longer need to import React in your files to use React. Confused? This article will tell you what you need to know in order to migrate both your code and knowledge to this new way of doing things.
The Replay is a weekly newsletter for dev and engineering leaders.
Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.
If youâve ever written React, youâve probably noticed the weird HTML-looking syntax in regular JavaScript files. That syntax is called JSX, and is not valid JavaScript. It looks like this:
const Welcome = () => {
return <h1 className="hero">Welcome!</h1>;
};
In order to run this in a browser, you need to run your code through a compiler, typically Babel or TypeScript, which changes your code to valid JavaScript. Because, as it turns out, JSX is just another way of writing this:
const Welcome = () => {
return React.createElement("h1", { className: "hero", children: "Welcome" });
};
So Babel or TypeScript (or whatever tool you choose) changes your code into calls to the function React.createElement â and therein lies the challenge. Because, suddenly, you have a reference to âReactâ in your code! If you havenât imported React at the top of your file, JavaScript doesnât know what to do with this compiled code either. Thatâs why you need to add import React from 'react' to the top of all your JSX-files.
Adding this to the top of all files is a huge stumbling block for beginners and a pain in the butt for the experts. And with React 17, you no longer need to specify it!
The React team has collaborated with the community to create a new transform, which automatically imports a new jsx-function from a new custom entry point. Your compiled code will now look like this:
import { jsx as _jsx } from "react/jsx-runtime";
const Welcome = () => {
return _jsx("h1", { className: "hero", children: "Welcome" });
};
This will also have a lovely side-effect of a potentially smaller bundle size!
First, I want to reiterate that this feature is only available in React 17âs release candidate right now. It will be back-ported to older versions as well, but if you want to try it out today, you need to stick with version 17.
What you need to do depends on what youâre using to write your React app.
If you have your own Babel config, you need to do a few more manual steps. If youâre using @babel/preset-react, update it to the newest version. If youâre using @babel/plugin-transform-react-jsx, update that one instead. And update @babel/core as well, while youâre at it.
npm update @babel/core @babel/preset-react # or npm update @babel/core @babel/plugin-transform-react-jsx
Next, update your Babel config with the following snippets:
{
"presets": [
[
"@babel/preset-react",
{
"runtime": "automatic"
}
]
]
}
or
{
"plugins": [
[
"@babel/plugin-transform-react-jsx",
{
"runtime": "automatic"
}
]
]
}
And youâre done!
Well, almost done. Because now you have tons of imports that arenât necessary anymore! And we canât let them hang around, can we?
Well, actually, you can. Everything will work as normal and will continue to do so for the foreseeable future. But having dead code hanging around is just a nuisance, and if you have the resources to get them removed, why not?
Instead of going through all your hundreds of components removing this by hand, the great people over at the React team have written an automatic script (a so-called codemod) that does it all for us. đ All you need to do is the following:
npx react-codemod update-react-imports
This will remove all imports to the default React export (import React from 'react'), and rewrite any references to hooks and other functions as named imports instead. That means React.useEffect will change to useEffect instead, and an import { useEffect } from 'react' statement will be added to the top of your file.
This latter part took me by surprise (Iâve always written them with prefix because I find it easier to both read and write), but it clears the way for creating an ES module build of React in the future. Iâm sure Iâll get used to it after a while đ
With this annoying React import out of the way, React will be even easier to learn. Thereâs one less concept to remember, and things work better out of the box. And one line less to write whenever youâre bootstrapping a new JSX file.
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
Learn more â
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
Promise.all still relevant in 2025?In 2025, async JavaScript looks very different. With tools like Promise.any, Promise.allSettled, and Array.fromAsync, many developers wonder if Promise.all is still worth it. The short answer is yes â but only if you know when and why to use it.
Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 29th issue.
Learn about the new features in the Next.js 16 release: why they matter, how they impact your workflow, and how to start using them.
Test out Meta’s AI model, Llama, on a real CRUD frontend projects, compare it with competing models, and walk through the setup process.
Would you be interested in joining LogRocket's developer community?
Join LogRocketâs Content Advisory Board. Youâll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
One Reply to "Diving into the new JSX transform"
omg for reals? importing react bothered no developer ever, especially when most of us use auto-populating snippets… aside from maybe bundle size, this is the most underwhelming upgrade EVER!