DEV Community: melodyLeonard

NEW JSX TRANSFORM

melodyLeonard — Mon, 25 Jan 2021 18:27:25 +0000

What is JSX?

JSX stands for JavaScript XML. A JavaScript wrapper around HTML tags. The JSX is more powerful than the traditional HTML.

It is built to allow React show more useful error and warning messages as well as other cool features that does'nt come with the traditional HTML.
You can read more about the cool feature of JSX in the React JSX Introduction

The New JSX Transform

JavaScript XML (JSX) which allows us to write HTML in react is not understood by the browser out of the box. Hence react developers rely on compilers like Babel or typescript to transform JSX code into regular JavaScript.
Even the preconfigured create react app toolkit include a JSX transform under the hood.

After the release of react 17, the Facebook team made an improvement to JSX transform. The team worked with babel to offer a new rewritten JSX transform for react users.

With the new transform, one can use JSX without importing react
Also the compiled output may also improve the bundle size which may depend on ones setup.

This update as promised by the team would not change the current JSX syntax and upgrading to the new JSX transform is not required. So users who are currently using the older transform do not have to upgrade if they choose not to as the old JSX transform will keep working as usual.

What’s Different in the New Transform?

Normally when we us JSX, the compiler transforms it into React function calls that the browser can understand. This means that The older JSX transform would turn JSX into

React.createElement()

For example, lets say we have a simple function component that says Hello World

import React from 'react';

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

Under the hood, the old JSX transform would turn the JSX into regular JavaScript:

import React from 'react';

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

However, this is not perfect:

Because JSX was compiled into React.createElement, React needed to be in scope if you used JSX. Hence, the reason react is being imported everywhere you use JSX
Also, there are some performance improvements and simplifications that that are not allowed by React.createElement()

Hence when react 17 was released to make react upgrade easier and backward compatible, it also introduced two new entry points to the react package that are intended to only be used by compilers like Babel and typescript. So 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.

So for our hello World functional component

import React from 'react';

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

The new Jsx transform would compile it to:

// The import would be Inserted by the compiler (don't import it yourself)
import {jsx as _jsx} from 'react/jsx-runtime';

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

Now we can see that with the new JSX transform, we didn’t have to import react. This optimizes our code and gives us access to those performance improvement that JSX React.createElement() doesn’t allow.

Though this is true with JSX, we would still need to import React to use hooks or other exports that React provides

Want to Upgrade to the New JSX Transform?

If you wish to upgrade the new Jsx transform you would need these:

A version of React that supports the new transform. For example React 17 RC and higher supports it. But the facebook team has also released React 16.14.0, React 15.7.0 and React 0.14.10 for people who are still on the older major versions
A compatible compiler such as:
- Create React App v4.0.0+
- Next.js v9.5.3+
- Gatsby v2.24.5+

some times with gatsby, one gets a gatsby error such as:

This can be fixed by running

npm update

New JSX Transform Supported Compilers Versions and Configurations

Babel v7.9.0 First, you’ll need to update to the latest Babel and plugin transform. If you are using @babel/plugin-transform-react-jsx:

For npm run:

npm update @babel/core @babel/plugin-transform-react-jsx

For yarn run:

yarn update @babel/core @babel/plugin-transform-react-jsx

If you are using @babel/preset-react:

npm update @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"
    }]
  ]
}

It is proposed that by Babel 8, "automatic" will be the default runtime for both plugins.

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"
  }
}

Typesript:
Typesript supports the Jsx transform from version v4.1.
Flow:
Flow supports the Jsx transform from version v0.126.0

Type System for Javascript

melodyLeonard — Fri, 04 Dec 2020 18:53:57 +0000

JavaScript is a dynamically-typed language. What this means is that it performs type checking at runtime.

Take for instance a language like java or C++ which is a statically-typed language. Type checking in such language is performed at compile time. This is very useful as it warns the programmer of all type errors before the code executes successfully. This way, programmers are subjected to writing lesser error codes.

In C++ you would have to define a variable type before using it; You cannot assign a variable with the wrong data type. Hence, it ensures all your variables are checked to make sure they have the right datatype before the code is compiled.

For example, in C++, you would define an integer as:

int amount = 200;

this is correct and would compile successfully, then run successfully as well because 200 is an integer.

On the other hand, if you tried to declare

int amount = “200”;

this would fail at compile-time and you would have a compile-time error. Now this error is very useful as it warns you of a bug in your code before the program runs; helping you to fix it and preventing you from pushing a buggy code out for production.

JavaScript has a different approach to assigning a datatype to a variable. JavaScript allows the kind of data being stored to define datatype at any given time.

For instance in JavaScript, if you define a variable:

var amount =   200;

then later do:

var amount = “200”

...both cases would compile successfully and even run successfully.

Now the fact that this compiles and runs successfully does not mean the code run as intended.

For a real world application, this simple bug could be a huge threat to the life of an organization.

In the first instance, JavaScript would infer the type of the variable amount to be an integer. Later this type inference would get overwritten and JavaScript would infer the amount to be a string in the second instance.

If this code was part of a software handling some financial transactions, were the total amount in a certain user account is to be the sum of all the money coming in to the account. Then the outcome of the total amount in any user account would be wrong.

For example if:

var prevAmount = 500;

var currAmount = “200”

var totalAmount = prevAmount + currAmount

console.log(totalAmount)

Now the program is expected to have 700 as the total amount but because the prevAmount is an integer and the currAmount is a string, JavaScript performs an implicit conversion on prevAmount, which becomes a string. Then concatenation is done on both instead of expected addition.

Therefore:

totalAmount = 500200

...This gives the user more money than should and puts the organization at risk.

IMPLICIT VS EXPLICIT CONVERSION

An implicit conversion is a conversion done by a language to change a datatype to another datatype so they can perform a certain operation. This is very possible in JavaScript because during variable initialization, datatype is not defined. Instead the datatype of a variable is established from the kind of data the variable holds

Whereas an explicit conversion is a conversion stated by a programmer to change the datatype of a variable intentionally.

An example of an explicit conversion would be:

var totalAmount = prevAmount.toInt() + currAmount.toInt()

By performing the explicit conversion, each amount would be converted to an integer before addition is done.

Now you may ask:
"Why can’t I just do this and avoid using a type checker for my code".

Well you can but you would have to remember to do so in every part of your code where necessary and also, your code would still compile even though you forget to do so in some instance. This means that you are prone to getting unintended results.

We want to avoid a buggy code compiling as much as possible .
We want all errors fixed before our code finally runs. So that when it finally does, we know for sure we are not having unintended behaviors from type errors.

The differences between static type checking and dynamic type checking can be seen when a type error occurs. In a statically-typed language, type errors occur during compile time.

Whereas in dynamically-typed languages, the errors occur only once the program is executed. That is, at runtime.

This means that a program written in a dynamically-typed language (like JavaScript or Python) can compile even if it contains type errors that would otherwise prevent the code from running properly.

On the other hand, if a program written in a statically-typed language (like Java or C++) contains a type error, it will fail to compile until the error has been fixed.

The two powerful most used tools that helps you perform type-checking in JavaScript are:

Flow
Typescript