React 17 Tag

What’s JSX Transform?

Browsers don’t understand JSX out of the box, so most React users rely on a compiler like Babel or TypeScript to transform JSX code into regular JavaScript. Many preconfigured toolkits like Create React App or Next.js also include a JSX transform under the hood.

Together with the React 17 release, we’ve wanted to make a few improvements to the JSX transform, but we didn’t want to break existing setups. This is why we worked with Babel to offer a new, rewritten version of the JSX transform for people who would like to upgrade.

Upgrading to the new transform is completely optional, but it has a few benefits:

• With the new transform, you can use JSX without importing React.
• Depending on your setup, its compiled output may slightly improve the bundle size.
• It will enable future improvements that reduce the number of concepts you need to learn React.

This upgrade will not change the JSX syntax and is not required. The old JSX transform will keep working as usual, and there are no plans to remove the support for it.

React 17 RC already includes support for the new transform, so go give it a try! To make it easier to adopt, after React 17 is released, we also plan to backport its support to React 16.x, React 15.x, and React 0.14.x. You can find the upgrade instructions for different tools below.

Now let’s take a closer look at the differences between the old and the new transform.

What’s Different in the New Transform?

When you use JSX, the compiler transforms it into React function calls that the browser can understand. The old JSX transform turned JSX into React.createElement(…) calls.

For example, let’s say your source code looks like this:

import React from 'react';

function App() {
  return <h1>Hello World</h1>;
}

Under the hood, the old JSX transform turns it into regular JavaScript:

import React from 'react';

function App() {
  return React.createElement('h1', null, 'Hello world');
}

Note
Your source code doesn't need to change in any way. We're describing how the JSX transform turns your JSX source code into the JavaScript code a browser can understand.

However, this is not perfect:

• Because JSX compiled into React.createElement, React needed to be in scope if you use JSX.
• There are some performance improvements and simplifications that React.createElement does not allow.

To solve these issues, React 17 introduces two new entry points to the React package that are intended to only be used by compilers like Babel and TypeScript. Instead of transforming JSX to React.createElement, the new JSX transform automatically imports special functions from those new entry points in the React package and calls them.

Let’s say that your source code looks like this:

function App() {
  return <h1>Hello World</h1>;
}

This is what the new JSX transform compiles it to:

// Inserted by a compiler (don't import it yourself!)
import {jsx as _jsx} from 'react/jsx-runtime';

function App() {
  return _jsx('h1', { children: 'Hello world' });
}

Note how our original code did not need to import React to use JSX anymore! (But we would still need to import React in order to use Hooks or other exports that React provides.)

This change is fully compatible with all of the existing JSX code, so you won’t have to change your components. If you’re curious, you can check out the technical RFC for more details about how the new transform works.

Note
The functions inside react/jsx-runtime and react/jsx-dev-runtime must only be used by the compiler transform. If you need to manually create elements in your code, you should keep using React.createElement. It will continue to work and is not going away.

How to Upgrade to the New JSX Transform

If you aren’t ready to upgrade to the new JSX transform or if you are using JSX for another library, don’t worry. The old transform will not be removed and will continue to be supported.

If you want to upgrade, you will need two things:

• A version of React that supports the new transform (currently, only React 17 RC supports it, but after React 17.0 has been released, we plan to make additional compatible releases for 0.14.x, 15.x, and 16.x).
• A compatible compiler (see instructions for different tools below).

Since the new JSX transform doesn’t require React to be in scope, we’ve also prepared an automated script that will remove the unnecessary imports from your codebase.

Create React App

Create React App support has been added and will be available in the upcoming v4.0 release which is currently in beta testing.

Next.js

Next.js v9.5.3+ uses the new transform for compatible React versions.

Gatsby

Gatsby v2.24.5+ uses the new transform for compatible React versions.

Note
If you get this Gatsby error after upgrading to React 17.0.0-rc.2, run npm update to fix it.

Manual Babel Setup

Support for the new JSX transform is available in Babel v7.9.0 and above.

First, you’ll need to update to the latest Babel and plugin transform.

If you are using @babel/plugin-transform-react-jsx:

# for npm users
npm update @babel/core @babel/plugin-transform-react-jsx

# for yarn users
yarn upgrade @babel/core @babel/plugin-transform-react-jsx

If you are using @babel/preset-react:

# for npm users
npm update @babel/core @babel/preset-react

# for yarn users
yarn upgrade @babel/core @babel/preset-react

Currently, the old transform (“runtime”: “classic”) is the default option. To enable the new transform, you can pass {“runtime”: “automatic”} as an option to @babel/plugin-transform-react-jsx or @babel/preset-react:

// If you are using @babel/preset-react
{
  "presets": [
    ["@babel/preset-react", {
      "runtime": "automatic"
    }]
  ]
}

// If you're using @babel/plugin-transform-react-jsx
{
  "plugins": [
    ["@babel/plugin-transform-react-jsx", {
      "runtime": "automatic"
    }]
  ]
}

Starting from Babel 8, “automatic” will be the default runtime for both plugins. For more information, check out the Babel documentation for @babel/plugin-transform-react-jsx and @babel/preset-react.

Note
If you use JSX with a library other than React, you can use the importSource option to import from that library instead - as long as it provides the necessary entry points. Alternatively, you can keep using the classic transform which will continue to be supported.

ESLint

If you are using eslint-plugin-react, the react/jsx-uses-react and react/react-in-jsx-scope rules are no longer necessary and can be turned off or removed.

{
  // ...
  "rules": {
    // ...
    "react/jsx-uses-react": "off",
    "react/react-in-jsx-scope": "off"
  }
}

TypeScript

TypeScript supports the JSX transform in v4.1 beta.

Flow

Flow supports the new JSX transform in v0.126.0 and up.

Removing Unused React Imports

Because the new JSX transform will automatically import the necessary react/jsx-runtime functions, React will no longer need to be in scope when you use JSX. This might lead to unused React imports in your code. It doesn’t hurt to keep them, but if you’d like to remove them, we recommend running a “codemod” script to remove them automatically:

cd your_project
npx react-codemod update-react-imports

Note
If you're getting errors when running the codemod, try specifying a different JavaScript dialect when npx react-codemod update-react-imports asks you to choose one. In particular, at this moment the "JavaScript with Flow" setting supports newer syntax than the "JavaScript" setting even if you don't use Flow. File an issue if you run into problems.

Keep in mind that the codemod output will not always match your project's coding style, so you might want to run Prettier after the codemod finishes for consistent formatting.

Running this codemod will:

• Remove all unused React imports as a result of upgrading to the new JSX transform.
• Change all default React imports (i.e. import React from “react”) to destructured named imports (ex. import { useState } from “react”) which is the preferred style going into the future. This codemod will not affect the existing namespace imports (i.e. import * as React from “react”) which is also a valid style. The default imports will keep working in React 17, but in the longer term we encourage moving away from them.

For example,

import React from 'react';

function App() {
  return <h1>Hello World</h1>;
}

will be replaced with

function App() {
  return <h1>Hello World</h1>;
}

If you use some other import from React – for example, a Hook – then the codemod will convert it to a named import.

For example,

import React from 'react';

function App() {
  const [text, setText] = React.useState('Hello World');
  return <h1>{text}</h1>;
}

will be replaced with

import { useState } from 'react';

function App() {
  const [text, setText] = useState('Hello World');
  return <h1>{text}</h1>;
}

In addition to cleaning up unused imports, this will also help you prepare for a future major version of React (not React 17) which will support ES Modules and not have a default export.

For more information and to develop web application using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop custom web apps using React JS, please visit our technology page.

Content Source:

1. medium.com

What’s new actually in React v17.0

It has been two and a half years since React v16 was first released. The dev team promises that update v17 is incredibly important for the future of React but claims that no new features are being added. So what exactly does that mean? And how can React claim to be releasing a major new version without adding new features?

Gradual React updates

Past React updates have always caused deprecations of older versions. This could make it incredibly difficult for teams to upgrade their React versions, especially when working with large or neglected codebases. So, the React team has decided that v17 will lay the groundwork for a new method of adopting updates. When React v18 is released, developers will be able to choose to only upgrade parts of their app and keep other parts running on v17. React advises against this if you’re application is actively maintained or in large-scale production, but it can help teams who don’t actively maintain their application or who don’t need to migrate certain components to the newer version. In the future, new React versions won’t leave these apps behind or demand massive migrations.

To enable this ability, the React team has spent some time reworking the event system. These updates are what caused React v17 to be a major release since it could potentially break many applications.

Events are no longer attached to the document

Contrary to what you might think, React doesn’t attach events to individual elements. Instead, React binds one handler per event type to the document node. This approach increases performance in applications with large element trees and also enables features like replaying events.

In the background, React can capture an event and determine which component to call before propagating the event up the component tree. However, in native Javascript, the event has already propagated to the document level. While this may not sound like an issue, this system breaks when running multiple instances of React. If a React app nested inside of another one has stopped the propagation of the event, the parent React app will still capture the event. This was a major headache for developers looking to nest different versions of React. You may not think that this happens in production, but the Atom code editor encountered this issue four years ago!

React will now attach event handlers to the root node of the React app. This change will allow the safe nesting of React trees within each other. Granted, all React instances will have to be running on version 17 or higher for this to work. This update also means that React apps are easier to embed inside of other frameworks like jQuery. React will now stop events from propagating to jQuery as one would expect.

Optimizing effect cleanup

It is fairly common to return a cleanup function within a useEffect method to stop any code running within the function. In the past, this cleanup function would run synchronously before the next frame was drawn. In reality, most apps don’t require screen updates to be delayed will running cleanup methods. So they will now run asynchronously after React has rendered the next frame. This should result in faster switch times between components. You can still use the useLayoutEffect method to run a cleanup method that blocks the render loop.

No more event pooling

Event pooling is incredibly confusing and doesn’t provide any optimizations on modern browsers. Instead, it can result in some strange bugs when working with multiple components that receive the same event. One event handler might set the event to be null, and thus the other components using the event would run into a null variable error. In short, newer React version will allow event fields to be accessed whenever you need them.

React v17 may not be the feature-packed update React developers were hoping for. It is instead more of a piece-of-mind update. So while we may not be getting cool new components or hooks, these additions will pay off down the road in later updates. You can try React v17 now by running npm install react@17.0.0-rc.0 react-dom@17.0.0-rc.0 in your React project.

For more information and to develop web application using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop custom web apps using React JS, please visit our technology page.

Content Source:

1. medium.com