DEV Community: Cibi Aananth

Fix React.useState using "as const"

Cibi Aananth — Mon, 26 Jun 2023 13:22:21 +0000

Let's take a typical React Component that fetches data from an external source and updates the UI based on the network state

// Users.tsx
import { useState, useEffect } from "react";

export const REQUEST_STATUS = {
  idle: "IDLE",
  pending: "PENDING",
  success: "SUCCESS",
  error: "ERROR",
};

async function fetchUsers(): Promise<{ name: string; id: number }[]> {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve([{ name: "User 1", id: 1 }]);
    }, 2000);
  });
}

export function App() {
  const [networkState, setNetworkState] = useState(REQUEST_STATUS.idle);
  const [users, setUsers] = useState<{ name: string; id: number }[]>([]);

  useEffect(() => {
    setNetworkState(REQUEST_STATUS.pending);
    // or setNetworkState("IDLE"); // valid
    const getUsers = async () => {
      const users = await fetchUsers();
      setUsers(users);
      setNetworkState(REQUEST_STATUS.success);
    };
    getUsers();
  }, []);

  return (
    <div>
      {networkState === "PENDING" ? (
        <p>Fetching data...</p>
      ) : (
        networkState === "SUCCESS" && (
          <li>
            {users?.map((user) => (
              <ul key={user.id}> {user.name} </ul>
            ))}
          </li>
        )
      )}
      {networkState === "ERROR" && (
        <div>An error occured while fetching users</div>
      )}
    </div>
  );
}

At first glance, this code may seem perfectly fine and in fact, this will render the component without any error.

BUT...

Let's assume that the REQUEST_STATUS is imported from some global file and used in our components like,

import { REQUEST_STATUS } from '../some/other/file'

and someone changed the statuses in the global file to something that breaks our Users.tsx component. Boom!

export const REQUEST_STATUS = {
  idle: "idle",
  pending: "pending",
  success: "success",
  error: "error",
};

Typechecking in `useState`

While adding a type to the setNetworkState is the ultimate fix to this problem, how do we do it without much change in the code?

First, let's infer the type of REQUEST_STATUS in our User component,

Here the type of the keys idle, pending, success, error is inferred as a string therefore using keyof and typeof would still result in string as the overall type.

Detour - `keyof` `typeof`

If the above syntax is confusing, let me break it down for you ;) Otherwise, skip to the next section.

`typeof`

Here TypeScript is going to be able to infer the type of your object for you. It's going to lift this object that you created from the value level to the type level.

so essentially typeof REQUEST_STATUS will be inferred as { idle: string, pending: string, success: string, error: string }

So if we want to get a type of particular key in the object, we can do something like

type IDLE_TYPE = typeof REQUEST_STATUS["idle"]; // string
type PENDING_TYPE = typeof REQUEST_STATUS["pending"]; // string
type SUCCESS_TYPE = typeof REQUEST_STATUS["success"]; // string
type ERROR_TYPE = typeof REQUEST_STATUS["error"]; // string

`keyof`

The keyof operator can be used to extract the keys of an object type.

keyof can be used in conjunction with typeof to create a union type of all keys in the object.

By extracting all the keys of the object type, we can combine these keywords to create union types

type REQUEST_TYPE = tyepof REQUEST_STATUS[keyof typeof REQUEST_STATUS] // string

// the above expression is equivalent to
type REQUEST_TYPE =
| { idle: string, pending: string, success: string, error: string }["idle"] 
| { idle: string, pending: string, success: string, error: string }["pending"]
| { idle: string, pending: string, success: string, error: string }["success"]
| { idle: string, pending: string, success: string, error: string }["error"]

Back to rescue with "as const"

Now that we know how typeof and keyof can be used together to create union type from objects, let's see how "as const" fits in here.

The above type export type REQUEST_TYPE = tyepof REQUEST_STATUS[keyof typeof REQUEST_STATUS] returns string as the type, so if typing our setState wouldn't solve our problem. This is because as long as we set a "string", TypeScript accepts it as a valid value.

import { REQUEST_TYPE, REQUEST_STATUS } from '../some/other/file'

const [networkState, setNetworkState] = useState<REQUEST_TYPE>(REQUEST_STATES.idle);

// ...somewhere in the code, we can still do
setNetworkState("idle"); // no error
setNetworkState("invalid_state"); // no error
setNetworkState(12) // Error as type "string" is inferred from initial state

Without further explanation, this is where "as const" assertion comes into play and makes it strongly typed. By simply adding as const to the object we can make it as readonly and ensure that all properties are assigned the literal type instead of a more general version like string or number

Combining with our previously learned trick we can create a union type of object values

Putting it together

// types
export const REQUEST_STATUS = {
  idle: "IDLE",
  pending: "PENDING",
  success: "SUCCESS",
  error: "ERROR",
} as const;

export type REQUEST_TYPES = typeof REQUEST_STATUS[keyof typeof REQUEST_STATUS];

// User.tsx
const [networkState, setNetworkState] = useState<REQUEST_TYPES>(REQUEST_STATUS.idle);

With this updated useState, TypeScript compiler will throw an error for invalid statuses.

Conclusion

In conclusion, using "as const" in conjunction with typeof and keyof can help you create strongly typed union types for your React useState hook, preventing potential bugs caused by unexpected value changes in your application. By implementing this approach, you'll ensure better type safety and maintainability in your codebase.

Happy coding!

React.FC is fixed?

Cibi Aananth — Thu, 15 Jun 2023 19:14:18 +0000

React.FC was removed from create-react-app in Jan 2020 due to two drawbacks, but with the release of TypeScript 5.1 and React 18, these issues have been resolved, allowing components to return various types without errors and improving type safety.

React.FC received love and hate from the React community and at some point it was criticized enough to get itself removed from create-react-app back on Jan 23, 2020. But why?

Cannot type components returning undefined, string or number although it is a perfectly valid syntax.
Implicitly includes children in props type

Now with the latest release of TypeScript 5.1 and React 18, it no longer displays those squiggly red lines.

What does that mean?

Let's take an example of a functional component that returns a string,

const Greet: React.FC = () => {
  return "Hello World"
};

before TypeScript 5.1 and React 18, this would throw an error as
Type '() => string' is not assignable to type 'FC<{}>'. Type 'string' is not assignable to type 'ReactElement<any, any>'.ts(2322)
But now with a newer version, this is a perfectly valid syntax.

Another example covering the 2nd drawback of React.FC,

const Button: React.FC = () => {
  return <button>Click me</button>;
};

export const App = () => {
  <Button>Boop</Button>; // valid syntax
};

In the above example, the Button component does not accept children but TypeScript doesn't warn you if you try to provide children Boop like <Button>Boop</Button>

Now with the newer versions, the above code would throw an error as

Type '{ children: string; }' has no properties in common with type 'IntrinsicAttributes'.ts(2559)

What changed?

Well, React fixed these typings by replacing the return type of React.FC from React.ReactElemet to React.ReactNode

What's the difference?

React.ReactElement type is defined as,

interface ReactElement<
  P = any,
  T extends string | JSXElementConstructor<any> =
    | string
    | JSXElementConstructor<any>
> {
  type: T;
  props: P;
  key: Key | null;
}

which means that it breaks when you attempt to pass in a string, number, or undefined as a child.

Whereas React.ReactNode is defined as a type that accepts all possible types that React can render.

type ReactNode =
  | ReactChild
  | ReactFragment
  | ReactPortal
  | boolean
  | null
  | undefined;

type ReactFragment = {} | Iterable<ReactNode>;
type ReactText = string | number;
type ReactChild = ReactElement | ReactText;
interface ReactPortal extends ReactElement {
  key: Key | null;
  children: ReactNode;
}

Conclusion

In conclusion, the latest TypeScript 5.1 and React 18 updates have addressed the issues with React.FC, allowing components to return various types such as strings, numbers, and undefined without errors. This improvement enhances the developer experience and ensures better type safety when using functional components in React applications.

Hoisting in JavaScript: One last time

Cibi Aananth — Tue, 13 Jun 2023 16:10:00 +0000

Hello JavaScript enthusiasts! Today, we're diving into one of JavaScript's most interesting behaviours: Hoisting.

This strange-sounding term might be a source of confusion, but worry not! We're here to unravel its mysteries, all while keeping things fun and engaging. So grab your diving gear, it's time for a deep dive!

Hoisting - What's That?

In the magical world of JavaScript, hoisting is a peculiar behaviour where variable and function declarations are moved to the top of their containing scope during the compilation phase. But, let's make this clear: while it's helpful to picture declarations physically "moving up", what happens is JavaScript engine stores these declarations in memory during the parsing phase.

Now that we've briefly introduced hoisting, let's dive deeper into how different variable declarations are hoisted!

The Tale of 'var' Hoisting

When a variable is declared using var, JavaScript hoists it to the top of its function or global scope. However, it's initialized with undefined until it encounters the assignment in the code.

Here, myVar is known from the start, but it begins its life as undefined. Only when the assignment is reached, myVar finally becomes 5.

Yet another example,

In the above code snippet. even though the value of myVar is initialized to 5 before console statement it still prints undefined. Why? let's apply the rules of variable hoisting again,

Since myVar is redeclared again inside print, it is hoisted to print function scope and thus the value is undefined

'let' and 'const' Hoisting

Unlike var, let and const are hoisted too, but they aren't initialized. Attempting to access them before declaration leads us to an error-ridden place, known as the Temporal Dead Zone (TDZ).

So, even though myLet is hoisted, and trying to access it in its TDZ throws a ReferenceError. Always declare let and const before use!

Temporal Dead Zone (TDZ) - An Uncharted Territory

The TDZ is the period between entering scope and being declared where variables can't be accessed. It's JavaScript's way of encouraging us to declare variables before use.

Function Hoisting - A Different Beast

When it comes to function declarations, JavaScript treats them with special care. Both the name and body of function declarations are hoisted, allowing us to call the function even before it's declared!

That's right! We can use sum even before its declaration, thanks to hoisting.

Arrow Functions - The Cool Kid

Arrow functions, like function expressions, follow the hoisting rules of their variable declaration. If stored in a var variable, it's hoisted but initialized with undefined. If in a let or const, it resides in the TDZ until declaration.

Why does var implementation throw TypeError rather than ReferenceError?

According to var's hoisting rules with the following representation,

Here's the value of sum is undefined during sum(1,2) but we're trying to invoke a function call which is a TypeError

To wrap up, understanding hoisting and its nuances allows you to read and write JavaScript more effectively. It might seem like a quirk, but it's an integral part of the JavaScript landscape. So the next time you stumble upon a tricky piece of JavaScript code, remember, hoisting might be at play!

Happy Coding!

DEV Community: Cibi Aananth

Fix React.useState using "as const"

Typechecking in useState

Detour - keyof typeof

typeof

keyof

Back to rescue with "as const"

Putting it together

Conclusion

React.FC is fixed?

What does that mean?

What changed?

Conclusion

Hoisting in JavaScript: One last time

Hoisting - What's That?

The Tale of 'var' Hoisting

'let' and 'const' Hoisting

Temporal Dead Zone (TDZ) - An Uncharted Territory

Function Hoisting - A Different Beast

Arrow Functions - The Cool Kid

Typechecking in `useState`

Detour - `keyof` `typeof`

`typeof`

`keyof`