DEV Community: Armstrong Olusoji

How React19 optimizes rendering

Armstrong Olusoji — Sun, 10 Nov 2024 19:26:49 +0000

React 19 offers several new features. And some of those features improve rendering behavior. This is important because rendering is central to React. At its best, rendering improves performance and user experience. At its worst, it makes our apps unusable. This article, therefore, explores how React 19 optimizes rendering. It covers the following:

Form actions: a better way to handle forms, and the related asynchronous operations.
useOptimistic: a new way to improve user experience by displaying instant updates while waiting for asynchronous functions to complete.
React Compiler: Although not part of React 19, it optimizes rendering performance by automatically memoizing components.
Server Components: Reduce client-side rendering load by handling components on the server.

Please note that this article compares the new features with traditional React paradigms. Thus, only readers who have some React experience will appreciate it.

Streamlining Asynchronous Operations with Actions

Asynchronous (async) operations are crucial in programming. And managing them in React can be troublesome. For example, the current pattern to manage forms in React is as follows:

Store the form data in a state variable.
Modify the schema, or user interface with the form data.
Handle transitions and status updates with a different set of state variables.

The issue with this approach is that multiple state variables trigger multiple re-renders. Actions, however, are functions that handle all these things with neither state management nor event handlers. Without an action, you need several moving pieces. With an action, you only need one function. The image below illustrates this difference.

As seen above React 19 actions provide an easy way to handle async functions with minimal re-renders. Let us demonstrate this with a simple form component.

Testing a Form Action

A common React use case is to use the data collected from a form to do something on the server. Here's how to do that with a form action:

export default function Form() {
  async function handleSubmit(formData) {
    const name = formData.get("name");
    console.log(`Submitted: Name - ${name}`);
    // Simulate an API call
    await new Promise((resolve) => setTimeout(resolve, 3000));
    console.log(`The name: ${name} has been successfully sent to the server`);
  }

  return (
    <div>
      <form action={handleSubmit}>
        <label htmlFor="input">Name:</label>
        <input id="input" type="text" name="name" required />
        <button type="submit">Submit</button>
      </form>
    </div>
  );
}

The form action here is the async function handleSubmit. It automatically receives data from the form. In this case, formData represents that data.

We then use the .get method to query formData and collect the value with the key name.

Finally, In the JSX we append handleSubmit as the action. We also reference the input data with the prop name.

But what if - depending on the status of handleSubmit - we want to conditionally render a button? We would have to combine the action with a hook called useFormStatus().

Testing useFormStatus

In the second demonstration, we conditionally render the button with a new hook called useFormStatus(). When handleSubmit is in progress, the button with the text submitting will be rendered. To achieve this, we would typically use a state variable like:

const [isPending, setIsPending] = useState(true)

With useFormStatus(), we can simply do the following:

import React from "react";
import { useFormStatus } from "react-dom";

function Submit() {
  const { pending } = useFormStatus();
  return (
    <button type="submit" disabled={pending}>
      {pending ? "Submitting..." : "Submit"}
    </button>
  );
}

export default function Form() {
  async function handleSubmit(formData) {
    const name = formData.get("name");
    console.log(`Submitted: Name - ${name}`);
    // Simulate an API call
    await new Promise((resolve) => setTimeout(resolve, 3000));
    console.log(`The name: ${name} has been successfully sent to the server`);
  }

  return (
    <div>
      <form action={handleSubmit}>
        <label htmlFor="input">Name:</label>
        <input id="input" type="text" name="name" required />
        <Submit />
      </form>
    </div>
  );
}

Inside the Submit component, we call the useFormStatus() hook. This hook returns a status that is either true or false. Similar to a promise, the status represents the resolution of the operations in an async function. Thus If the target function has completed its work, the hook returns true. Otherwise it returns false.

In this example, we use the pending attribute of useFormStatus() to check if handleSubmit has executed all its code. Then, the button element renders a different text depending on the status of handleSubmit Finally, we use the Submit component inside the Form component.

Now that Submit is a child component of Form, handleSubmit becomes the target function. Thus useFormStatus() will read the status of handleSubmit.

So far we saved name, and simulated an API call with it. We have also changed the button based on the status of handleSubmit. Now, let us try a more advanced feature of actions.

Testing `useActionState()`

useActionState() is a hook that stores the state of a form Action and allows us to use it. For this example, we store the history of every name input.

import React, { useActionState } from "react";

export const Form = () => {
  const [nameData, actionFunction] = useActionState(handleSubmit, {
    currentName: "",
    nameHistory: [],
  });

  async function handleSubmit(prevState, formData) {
    await new Promise((resolve) => setTimeout(resolve, 1000)); // Simulating API call
    const newName = formData.get("name");

    // Update the name history, keeping only the last 3 names
    const updatedHistory = [prevState.currentName, ...prevState.nameHistory];

    return {
      currentName: newName,
      nameHistory: updatedHistory.filter(Boolean),
    };
  }

  return (
    <div>
      <form action={actionFunction}>
        <div>
          <label htmlFor="name">Enter your name:</label>
          <input type="text" id="name" name="name" required />
        </div>
        <Submit />
      </form>

      {nameData.currentName && <h2>{`Hello, ${nameData.currentName}!`}</h2>}

      {nameData.nameHistory.length > 0 && (
        <div>
          <h3>Previously entered names:</h3>
          <ul>
            {nameData.nameHistory.map((name, index) => (
              <li key={index}>{name}</li>
            ))}
          </ul>
        </div>
      )}
    </div>
  );
};

First, we define useActionState() by destructuring the returned array as follows:

[nameData, actionFunction]

nameData refers to the return value of our form action. actionFunction refers to the function we are targeting.

Inside the useActionState() hook, we set handleSubmit as the function to target and an object as the default value of nameData.

Next, handleSubmit() receives a prevState argument which represents the previous state of our form action. It automatically reads and stores the previous value of formData. Hence we can use prevState in a spread operator to create a history of names.

Finally, we make one last change to the JSX. We replace handleSubmit with actionFunction as the action. This is possible because actionFunction references handleSubmit

Recap: We have covered a lot here. Combined, these three hooks help us work with form conveniently. Without them, we would be keeping track of multiple state variables - causing several unnecessary re-renders.

useOptimistic

State changes trigger a render in React. But after that, React creates a new virtual DOM based on the new state. Then, it compares the new virtual DOM with the existing DOM, and updates the existing DOM. This process is called reconciliation.

But what if you want to display the future state of an element to the user? For example, if they edit their name you need to do the following asynchronous function:

Receive the new value
Make a put request to the server with the new value.
Make a get request from the server
Display the result of the get request on the client.
React will then build the new virtual DOM and perform reconciliation.

With this process, the user has to wait for some time before the change is visible. Yet, you can use an optimistic update to provide instant feedback.

useOptimistic is a way to display data on the interface before the underlying async functions are complete. With this hook, reconciliation happens between the optimistic state and the DOM.

Here's an example:

import { useOptimistic, useActionState } from "react";

function Form() {
  const [name, actionFunction] = useActionState(handleSubmit, "");
  const [optimisticName, setOptimisticName] = useOptimistic(name);

  async function handleSubmit(prevState, formData) {
    const newName = formData.get("name");

    await setOptimisticName(newName);
    await new Promise((resolve) => setTimeout(resolve, 1000)); // Simulating API call
    return `${newName}: returned from server`;
  }

  return (
    <>
      <form action={actionFunction}>    
          <input type="text" id="name" name="name" required />
        <button>submit</button>
      </form>
      <p>{optimisticName}</p>
    </>
  );
}

export default Form;

This component utilizes useActionState() for managing the form data and its state. You will also notice the useOptimistic hook. It works like useState()!

Inside handleSubmit we collect name from formData. Then we use its value with setOpimisticName().

In the JSX, we render optimisticName instead of name. Hence, while React waits for our async function to resolve, the optimistic state will immediately be rendered to the user. Once the async function resolves, React will render the new value of name. If the function is not resolved, React will render the old value of name.

The React Compiler

The new React compiler automatically optimizes rendering performance in React applications. The compiler's features are based on its understanding of React rules, and JavaScript. This allows it to automatically optimize the developer's code.

Without the compiler, developers optimize rendering with features such as useMemo, useCallback, and more. The below example is a component that would typically need useCallback:

import React, { useState } from "react";

function CounterDisplay({ count, setCount }) {
  console.log("CounterDisplay re-rendered", count);
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount((c) => c + 1)}>Increment</button>
    </div>
  );
}

function Counter() {
  const [count1, setCount1] = useState(0);
  const [count2, setCount2] = useState(0);

  console.log("Counter re-rendered");

  return (
    <div>
      <CounterDisplay count={count1} setCount={setCount1} />
      <CounterDisplay count={count2} setCount={setCount2} />
    </div>
  );
}

export default Counter;

CounterDisplay is a simple counter component. When a user clicks the Increment button, a message logs to the console.

Now, inside the Counter component, we render CounterDisplay twice. Open your console, you will notice that when we click on CounterDisplay1, CounterDisplay2 also re-renders. We, however, want to re-render only the CounterDisplay instance whose state has changed.

We would typically optimize this component with useCallback(). But the React compiler makes that unnecessary. Since the compiler understands JavaScript and React rules, it will automatically memoize the component. The compiler-optimized version of the above code is as follows:

function CounterDisplay(t0) {
  const $ = _c(7);  // Create a cache array with 7 elements
  const { count, setCount } = t0;
  console.log("CounterDisplay re-rendered", count);

  let t1;
  if ($[0] !== count) {  // Check if count has changed
    t1 = <p>Count: {count}</p>;  // Create new paragraph element
    $[0] = count;  // Update cache with new count
    $[1] = t1;  // Cache the new paragraph element
  } else {
    t1 = $[1];  // Reuse cached paragraph element if count hasn't changed
  }

  let t2;
  if ($[2] !== setCount) {  // Check if setCount function has changed
    t2 = <button onClick={() => setCount((c) => c + 1)}>Increment</button>;
    $[2] = setCount;
    $[3] = t2;
  } else {
    t2 = $[3];
  }


let t3;
  if ($[4] !== t1 || $[5] !== t2) {  // Check if either child element has changed
  t3 = (
  <div>
  {t1}
  {t2}
  </div>
  );  // Create a new div element with updated children
  $[4] = t1;  // Update cache with new t1 reference
  $[5] = t2;  // Update cache with new t2 reference
  $[6] = t3;  // Cache the new div element
  } else {
  t3 = $[6];  // Reuse cached div element if children haven't changed
  }
  return t3;
  }

The compiler code is not relevant to you, but it is worth noting what exactly it is doing to optimize the code.

The compiler creates a cache for each component as shown below:

const $ = \_c(7)

This cache stores the current and previous values; as well as rendered elements.

In the CounterDisplay component, the compiler checks if any relevant state variables have changed.
If anything has changed, the compiler creates a new <p> element with the latest value. It also updates the cache.
If nothing has changed it reuses the previously rendered version. This means that only elements whose states have changed will re-render.

This process is repeated inside the Counter component.

Note: We have only shown the compiler code for CounterDisplay. But a similar optimization will happen in Counter.

The optimized Counter function

function Counter() {
  const $ = _c(7);  // Create a cache array with 7 elements
  const [count1, setCount1] = useState(0);
  const [count2, setCount2] = useState(0);
  console.log("Counter re-rendered");
  let t0;
  if ($[0] !== count1) {  // Check if count1 has changed
    t0 = ;
    $[0] = count1;
    $[1] = t0;
  } else {
    t0 = $[1];  // Reuse cached CounterDisplay element if count1 hasn't changed
  }

  let t1;
  if ($[2] !== count2) {
    t1 = ;
    $[2] = count2;
    $[3] = t1;
  } else {
    t1 = $[3];
  }

  let t2;
  if ($[4] !== t0 || $[5] !== t1) {  // Check if either CounterDisplay element has changed
    t2 = (

        {t0}
        {t1}

    );  // Create new div element with updated children
    $[4] = t0;
    $[5] = t1;
    $[6] = t2;
  } else {
    t2 = $[6];  // Reuse cached div element if children haven't changed
  }
  return t2;
}

Server Components

Server components are the latest iteration in React's attempt to load content better. So far, we have client-side rendering (CSR), server-side rendering (SSR), and static site generation (SSG)

Leading up to Server Components

In CSR, JavaScript modules load, and HTML is built at request time. All this happens on the user's browser. There are two issues with this approach.

No content will rendered until the aforementioned protocol is complete.
The protocol is executed in the user's browser. As such, performance is subject to user-specific issues like network conditions.

SSR solves some of these issues. In SSR, the JavaScript modules run, and API calls happen on the server. The HTML is also built from the server, and then sent to the browser. This is a significant upgrade on CSR. Yet, both approaches are similar in that the HTML is built at the request time. In SSR, the user may see a shell of the content (such as a header) but not the full thing.

This leads us to SSG. SSG happens on the server, like SSR. But in SSG the HTML is built the moment the application mounts (at build time). Thus, all pages render before the user ever navigates to them. This approach, though, is only useful for static sites where nothing changes.

How Server Components are an upgrade

This all leads us to Server Components. Server Components are React components that exist on the server. Server Components improve on both SSR and SSG in the following ways:

SSG and SSR both require network requests to the server. However, server components are built on the server. This makes things faster
Server Components render only once. This eliminates unnecessary re-renders. However, it also means they do not support hooks or state management.
Sever Components render before bundling, or request time - a significant upgrade on both SSR and SSG.
Server Components can also read file systems, or other server resources without API calls. You don't need a web server for many use cases.
Server components can be asynchronous. Hence, the functions nested inside them can run without using useEffect.
Server Components support 'streaming'. This means that HTML renders as it is being built, with the rest following in real-time. This makes for quicker outcomes.

With these features, we can render things faster. This helps our website performance in metrics such as:

First Contentful Paint: when the user can see the layout.
Time To Interactive: when the user can interact with the interface.
Large Contentful Paint: all content, including content pulled from our database, are available. This is good for Search Engine Optimization, and user experience.

Conclusion

React 19's new features represent a significant leap forward in managing asynchronous operations and optimizing performance. By simplifying form handling, providing tools for optimistic updates, and introducing Server Components, React continues to evolve, offering developers more efficient ways to build responsive and user-friendly applications.

How React19 optimizes rendering

Armstrong Olusoji — Sun, 10 Nov 2024 19:26:48 +0000

Form actions: a better way to handle forms, and the related asynchronous operations.
useOptimistic: a new way to improve user experience by displaying instant updates while waiting for asynchronous functions to complete.
React Compiler: Although not part of React 19, it optimizes rendering performance by automatically memoizing components.
Server Components: Reduce client-side rendering load by handling components on the server.

Please note that this article compares the new features with traditional React paradigms. Thus, only readers who have some React experience will appreciate it.

Streamlining Asynchronous Operations with Actions

Asynchronous (async) operations are crucial in programming. And managing them in React can be troublesome. For example, the current pattern to manage forms in React is as follows:

Store the form data in a state variable.
Modify the schema, or user interface with the form data.
Handle transitions and status updates with a different set of state variables.

As seen above React 19 actions provide an easy way to handle async functions with minimal re-renders. Let us demonstrate this with a simple form component.

Testing a Form Action

A common React use case is to use the data collected from a form to do something on the server. Here's how to do that with a form action:

export default function Form() {
  async function handleSubmit(formData) {
    const name = formData.get("name");
    console.log(`Submitted: Name - ${name}`);
    // Simulate an API call
    await new Promise((resolve) => setTimeout(resolve, 3000));
    console.log(`The name: ${name} has been successfully sent to the server`);
  }

  return (
    <div>
      <form action={handleSubmit}>
        <label htmlFor="input">Name:</label>
        <input id="input" type="text" name="name" required />
        <button type="submit">Submit</button>
      </form>
    </div>
  );
}

The form action here is the async function handleSubmit. It automatically receives data from the form. In this case, formData represents that data.

We then use the .get method to query formData and collect the value with the key name.

Finally, In the JSX we append handleSubmit as the action. We also reference the input data with the prop name.

But what if - depending on the status of handleSubmit - we want to conditionally render a button? We would have to combine the action with a hook called useFormStatus().

Testing useFormStatus

const [isPending, setIsPending] = useState(true)

With useFormStatus(), we can simply do the following:

import React from "react";
import { useFormStatus } from "react-dom";

function Submit() {
  const { pending } = useFormStatus();
  return (
    <button type="submit" disabled={pending}>
      {pending ? "Submitting..." : "Submit"}
    </button>
  );
}

export default function Form() {
  async function handleSubmit(formData) {
    const name = formData.get("name");
    console.log(`Submitted: Name - ${name}`);
    // Simulate an API call
    await new Promise((resolve) => setTimeout(resolve, 3000));
    console.log(`The name: ${name} has been successfully sent to the server`);
  }

  return (
    <div>
      <form action={handleSubmit}>
        <label htmlFor="input">Name:</label>
        <input id="input" type="text" name="name" required />
        <Submit />
      </form>
    </div>
  );
}

Now that Submit is a child component of Form, handleSubmit becomes the target function. Thus useFormStatus() will read the status of handleSubmit.

So far we saved name, and simulated an API call with it. We have also changed the button based on the status of handleSubmit. Now, let us try a more advanced feature of actions.

Testing `useActionState()`

useActionState() is a hook that stores the state of a form Action and allows us to use it. For this example, we store the history of every name input.

import React, { useActionState } from "react";

export const Form = () => {
  const [nameData, actionFunction] = useActionState(handleSubmit, {
    currentName: "",
    nameHistory: [],
  });

  async function handleSubmit(prevState, formData) {
    await new Promise((resolve) => setTimeout(resolve, 1000)); // Simulating API call
    const newName = formData.get("name");

    // Update the name history, keeping only the last 3 names
    const updatedHistory = [prevState.currentName, ...prevState.nameHistory];

    return {
      currentName: newName,
      nameHistory: updatedHistory.filter(Boolean),
    };
  }

  return (
    <div>
      <form action={actionFunction}>
        <div>
          <label htmlFor="name">Enter your name:</label>
          <input type="text" id="name" name="name" required />
        </div>
        <Submit />
      </form>

      {nameData.currentName && <h2>{`Hello, ${nameData.currentName}!`}</h2>}

      {nameData.nameHistory.length > 0 && (
        <div>
          <h3>Previously entered names:</h3>
          <ul>
            {nameData.nameHistory.map((name, index) => (
              <li key={index}>{name}</li>
            ))}
          </ul>
        </div>
      )}
    </div>
  );
};

First, we define useActionState() by destructuring the returned array as follows:

[nameData, actionFunction]

nameData refers to the return value of our form action. actionFunction refers to the function we are targeting.

Inside the useActionState() hook, we set handleSubmit as the function to target and an object as the default value of nameData.

Finally, we make one last change to the JSX. We replace handleSubmit with actionFunction as the action. This is possible because actionFunction references handleSubmit

Recap: We have covered a lot here. Combined, these three hooks help us work with form conveniently. Without them, we would be keeping track of multiple state variables - causing several unnecessary re-renders.

useOptimistic

But what if you want to display the future state of an element to the user? For example, if they edit their name you need to do the following asynchronous function:

Receive the new value
Make a put request to the server with the new value.
Make a get request from the server
Display the result of the get request on the client.
React will then build the new virtual DOM and perform reconciliation.

With this process, the user has to wait for some time before the change is visible. Yet, you can use an optimistic update to provide instant feedback.

useOptimistic is a way to display data on the interface before the underlying async functions are complete. With this hook, reconciliation happens between the optimistic state and the DOM.

Here's an example:

import { useOptimistic, useActionState } from "react";

function Form() {
  const [name, actionFunction] = useActionState(handleSubmit, "");
  const [optimisticName, setOptimisticName] = useOptimistic(name);

  async function handleSubmit(prevState, formData) {
    const newName = formData.get("name");

    await setOptimisticName(newName);
    await new Promise((resolve) => setTimeout(resolve, 1000)); // Simulating API call
    return `${newName}: returned from server`;
  }

  return (
    <>
      <form action={actionFunction}>    
          <input type="text" id="name" name="name" required />
        <button>submit</button>
      </form>
      <p>{optimisticName}</p>
    </>
  );
}

export default Form;

This component utilizes useActionState() for managing the form data and its state. You will also notice the useOptimistic hook. It works like useState()!

Inside handleSubmit we collect name from formData. Then we use its value with setOpimisticName().

The React Compiler

Without the compiler, developers optimize rendering with features such as useMemo, useCallback, and more. The below example is a component that would typically need useCallback:

import React, { useState } from "react";

function CounterDisplay({ count, setCount }) {
  console.log("CounterDisplay re-rendered", count);
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount((c) => c + 1)}>Increment</button>
    </div>
  );
}

function Counter() {
  const [count1, setCount1] = useState(0);
  const [count2, setCount2] = useState(0);

  console.log("Counter re-rendered");

  return (
    <div>
      <CounterDisplay count={count1} setCount={setCount1} />
      <CounterDisplay count={count2} setCount={setCount2} />
    </div>
  );
}

export default Counter;

CounterDisplay is a simple counter component. When a user clicks the Increment button, a message logs to the console.

function CounterDisplay(t0) {
  const $ = _c(7);  // Create a cache array with 7 elements
  const { count, setCount } = t0;
  console.log("CounterDisplay re-rendered", count);

  let t1;
  if ($[0] !== count) {  // Check if count has changed
    t1 = <p>Count: {count}</p>;  // Create new paragraph element
    $[0] = count;  // Update cache with new count
    $[1] = t1;  // Cache the new paragraph element
  } else {
    t1 = $[1];  // Reuse cached paragraph element if count hasn't changed
  }

  let t2;
  if ($[2] !== setCount) {  // Check if setCount function has changed
    t2 = <button onClick={() => setCount((c) => c + 1)}>Increment</button>;
    $[2] = setCount;
    $[3] = t2;
  } else {
    t2 = $[3];
  }


let t3;
  if ($[4] !== t1 || $[5] !== t2) {  // Check if either child element has changed
  t3 = (
  <div>
  {t1}
  {t2}
  </div>
  );  // Create a new div element with updated children
  $[4] = t1;  // Update cache with new t1 reference
  $[5] = t2;  // Update cache with new t2 reference
  $[6] = t3;  // Cache the new div element
  } else {
  t3 = $[6];  // Reuse cached div element if children haven't changed
  }
  return t3;
  }

The compiler code is not relevant to you, but it is worth noting what exactly it is doing to optimize the code.

The compiler creates a cache for each component as shown below:

const $ = \_c(7)

This cache stores the current and previous values; as well as rendered elements.

In the CounterDisplay component, the compiler checks if any relevant state variables have changed.
If anything has changed, the compiler creates a new <p> element with the latest value. It also updates the cache.
If nothing has changed it reuses the previously rendered version. This means that only elements whose states have changed will re-render.

This process is repeated inside the Counter component.

Note: We have only shown the compiler code for CounterDisplay. But a similar optimization will happen in Counter.

The optimized Counter function

function Counter() {
  const $ = _c(7);  // Create a cache array with 7 elements
  const [count1, setCount1] = useState(0);
  const [count2, setCount2] = useState(0);
  console.log("Counter re-rendered");
  let t0;
  if ($[0] !== count1) {  // Check if count1 has changed
    t0 = ;
    $[0] = count1;
    $[1] = t0;
  } else {
    t0 = $[1];  // Reuse cached CounterDisplay element if count1 hasn't changed
  }

  let t1;
  if ($[2] !== count2) {
    t1 = ;
    $[2] = count2;
    $[3] = t1;
  } else {
    t1 = $[3];
  }

  let t2;
  if ($[4] !== t0 || $[5] !== t1) {  // Check if either CounterDisplay element has changed
    t2 = (

        {t0}
        {t1}

    );  // Create new div element with updated children
    $[4] = t0;
    $[5] = t1;
    $[6] = t2;
  } else {
    t2 = $[6];  // Reuse cached div element if children haven't changed
  }
  return t2;
}

Server Components

Server components are the latest iteration in React's attempt to load content better. So far, we have client-side rendering (CSR), server-side rendering (SSR), and static site generation (SSG)

Leading up to Server Components

In CSR, JavaScript modules load, and HTML is built at request time. All this happens on the user's browser. There are two issues with this approach.

No content will rendered until the aforementioned protocol is complete.
The protocol is executed in the user's browser. As such, performance is subject to user-specific issues like network conditions.

How Server Components are an upgrade

This all leads us to Server Components. Server Components are React components that exist on the server. Server Components improve on both SSR and SSG in the following ways:

SSG and SSR both require network requests to the server. However, server components are built on the server. This makes things faster
Server Components render only once. This eliminates unnecessary re-renders. However, it also means they do not support hooks or state management.
Sever Components render before bundling, or request time - a significant upgrade on both SSR and SSG.
Server Components can also read file systems, or other server resources without API calls. You don't need a web server for many use cases.
Server components can be asynchronous. Hence, the functions nested inside them can run without using useEffect.
Server Components support 'streaming'. This means that HTML renders as it is being built, with the rest following in real-time. This makes for quicker outcomes.

With these features, we can render things faster. This helps our website performance in metrics such as:

First Contentful Paint: when the user can see the layout.
Time To Interactive: when the user can interact with the interface.
Large Contentful Paint: all content, including content pulled from our database, are available. This is good for Search Engine Optimization, and user experience.

Conclusion

5 crucial facts about React Rendering

Armstrong Olusoji — Thu, 25 Jul 2024 10:13:51 +0000

As I built my first project with React, one recurring issue was unnecessary renders. Sometimes, components would re-render even though there was no obvious trigger. Other times, the app would re-render infinitely. This was frustrating.

I cleared my frustration by learning everything I could about react rendering. This article is the culmination of that effort. The outline is as follows:

What Triggers a Re-render in React
Diffing and Reconciliation
Parent, Child, and Expensive Components
State as a snapshot
Pure functions and side effects

React rendering has two phases: the render and commit phases. The ideas in this article cover the render phase. To fully appreciate it, you must have a good background in JavaScript and React.

What triggers a render in react?

The short answer? Changes in props and state. The long answer is as follows:
The document Object Model (DOM) is a tree-like structure that represents the HTML elements in a web page. The virtual DOM is React’s copy of the DOM. The virtual DOM represents JSX, State, and local variables of a React component.
A render is triggered when anything changes in the state.. React then creates a new virtual DOM. It also compares the new virtual DOM with the existing virtual DOM. Furthermore, it calculates the differences between both virtual DOMs. Finally, it uses the differences as a guide to update the real DOM. This is all part of the rendering process.

Diffing and Reconciliation

We established how changes in State trigger a re-render. But between the render trigger and updating the DOM, something important happens. React evaluates the new virtual DOM vs the existing virtual DOM to know exactly what needs to change.

How does this happen exactly?

When a render is triggered, React calls a render method on the components that changed. For a functional component, React will call FunctionComponenet(Props). But for a class-based component, reach will call classComponentInstance.render(). These render methods generate the output (JSX) for the component.

Next, the output is converted to a react element using React.CreateElement() method. Since react elements are plain JavaScript objects, the output becomes an object. We described this object tree earlier as the virtual DOM. Remember, DOM stands for Document Object Model, which means that it models an object. The code below explains this:

return React.createElement(
  'button', 
  { 
    onClick: () => alert('Clicked!'), 
    className: 'btn' 
  }, 
  'Click Me'
);

//becomes 

{
  type: 'button',
  props: {
    onClick: () => alert('Clicked!'),
    className: 'btn',
    children: 'Click Me'
  }
}

A new object is created when the render method creates the new virtual DOM. But the state of a React app at every moment is committed to memory. Thus, the existing virtual DOM still exists despite the creation of the new virtual DOM. This allows React to compare both objects and search for differences. The process of comparing those two objects is called diffing. The results from diffing form the basis of what React will change in the real DOM. The process of calculating those changes is called reconciliation.

Parent, Child, and Expensive Components

We have established how state changes trigger a react re-render. Yet, a component can re-render even when its own State has not changed. This happens because the re-rendering process always begins from the root component.

When a render is triggered, React will start searching all the components for changes. This will start from the root component, all the way down the tree. A component with a different state from the existing virtual DOM is then flagged. The flagged component - known as the ‘dirty component’ - then re-renders.

However, React’s default behavior is to render every child of a dirty component as well. So whether the child component has state changes of its own or not, it will re-render. This could cause issues, particularly if you have an expensive component on that tree. That is why you need to mitigate unnecessary re-renders.

Note: An expensive component is one with significant computational demands on your system.

Mitigating Unnecessary Re-Renders

To mitigate unnecessary re-renders, React provides several tools and techniques

React.memo:

This higher-order component prevents functional components from re-rendering if their props have not changed.

const MyComponent = React.memo((props) => {
  // Component logic
});

PureComponent:

For class components, extending React.PureComponent automatically implements a shallow prop and state comparison to prevent unnecessary re-renders.

class MyComponent extends React.PureComponent {
  render() {
    // Component logic
  }
}

useMemo:

Memoizes the result of a calculation or function to avoid recomputing it on every render.

const memoizedValue = React.useMemo(() => computeExpensiveValue(a, b), [a, b]);

useCallback:

Memoizes the function to prevent its recreation on every render, useful when passing functions to child components.

const memoizedCallback = React.useCallback(() => {
  doSomething(a, b);
}, [a, b]);

shouldComponentUpdate:

For fine-grained control, implement this lifecycle method in class components to determine whether a component should update.

class MyComponent extends React.Component {
  shouldComponentUpdate(nextProps, nextState) {
    // Return true or false based on custom logic
  }
}

Moving State Down:

Moving state down involves setting the state locally within the child component that requires it. This ensures that only the specific component needing the state will re-render when the state changes, rather than the entire parent component.

export default function App() {
  return (
    <>
      <Form />
      <ExpensiveTree />
    </>
  );
}

function Form() {
  let [inputValue, setInputValue] = useState('');
  return (
    <>
      <input 
        value={inputValue} 
        onChange={(e) => setInputValue(e.target.value)} 
      />
      <p>Input: {inputValue}</p>
    </>
  );
}

In this example, the color state is local to the Form component. Only the Form component re-renders when the color changes, leaving the ExpensiveTree component unaffected.

Moving Content Up:

If the state is needed in multiple components, you can move the content that doesn't depend on the state up, so only the component with the state re-renders. This technique involves restructuring your components to isolate the state-dependent parts.

export default function App() {
  return (
    <InputProvider>
      <DisplayMessage />
      <ExpensiveTree />
    </InputProvider>
  );
}

function InputProvider({ children }) {
  let [inputValue, setInputValue] = useState('');
  return (
    <div>
      <input 
        value={inputValue} 
        onChange={(e) => setInputValue(e.target.value)} 
      />
      {children}
    </div>
  );
}

function DisplayMessage() {
  return <p>Some static content</p>;
}

In this example:
The ColorPicker component handles the color state and the elements dependent on it.

The App component contains the parts of the tree that don't depend on the color state and passes them to ColorPicker as children.

This way, when the color state changes, only the ColorPicker component re-renders, and the ExpensiveTree component remains unaffected.

State as a snapshot

There are times when a function uses the value of a state variable. In cases like this, the function must always receive the latest version of the state variable. Otherwise, a stale value could lead to issues.
Stale values will be used in React when you use a state variable before it has been updated. This is possible because the state is not the state variable. The state may change, but the value itself takes a little time to change. This is due to a paradigm in React called 'state as a snapshot'.

According to the React documentation, the state is a snapshot in time. The state of a component at every given time goes to a memory bank outside of the component. When the state changes, a new entry goes to that memory bank. Thus, there are two snapshots. The snapshot for the previous state, and the snapshot for the updated state.

However, the snapshot/state is a reference to the variable, not the variable itself. React still needs to update the state variable with the new value. And that does not happen until after a re-render. Thus, a re-render is not just a response to a change in state, it is also used to update the state variable.

import React, { useState } from 'react';

function StaleSateExample() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState('');

  const handleIncrement = () => {
    setCount(prevCount => prevCount + 1);
    // The `handleNameChange` function will use the stale value of `count`
    // because it captures the `count` value at the time it's defined
    handleNameChange(`Count: ${count}`);
  };

  const handleNameChange = (newName) => {
    setName(newName);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <p>Name: {name}</p>
      <button onClick={handleIncrement}>Increment</button>
    </div>
  );
}

When we test this code, ‘name’ ought to be the same value as ‘count’. But see what happens instead:

That is because handlNameChange receives the old version of count, and not the updated one. You could fix it by doing the state update with a call call-back function. When you use a callback function as the argument for a state setter, react will ensure that it always receives the latest value.

import React, { useState } from "react";

export default function StaleSateExample() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState("");

  const handleIncrement = () => {
    setCount((prevCount) => {
      const newCount = prevCount + 1;
      const handleNameChange = (newName) => setName(newName);
      handleNameChange(`Count: ${newCount}`);
      return newCount;
    });
  };

  return (
    <div>
      <p>Count: {count}</p>
      <p>Name: {name}</p>
      <button onClick={handleIncrement}>Increment</button>
    </div>
  );
}

If you try it again, it works as expected.

Pure functions and side effects

React expects pure functions that have no side effects. Violating this expectation will lead to unexpected behavior.

A pure function is a formulaic function that given the same input will always return the same output. In mathematics, 2 + 2 is always 4. 3 x 3 is always 9. These arithmetic operations will not change. It is like a recipe. You will produce the same final product if you use the same ingredients and follow the cooking instructions precisely. Likewise, every function you intend to render in react must be pure.

Furthermore, your functions should have no side effects. A side effect happens when a function mutates or affects variables that come before it. The below code snippet is an example of a side effect.

let counter = 0;

function Cup() {
  // Bad: changing a pre-existing variable!
  counter = counter + 1;
}

Conclusion

Rendering is an important part of react. Part of what made react revolutionary when it was first released was the idea of the virtual dom. It updated the DOM only with what had changed in the virtual DOM. Rendering is central to this whole paradigm. So understanding rendering will help you write better react.

How Next router handles routing differently from React Router Dom

Armstrong Olusoji — Fri, 28 Jun 2024 16:22:32 +0000

React and Next.js are similar in some ways, and different in others. One of those differences is in how both frameworks handle routing. As someone who has used React for most of my career, I was surprised to find how different Next.js routing is from React Routing. Understanding these differences is crucial for developers working with either framework. I will continue to update this article as I learn more about Next routing. But for now, this article will cover the following:

Declarative vs file-based routing
Dynamic routing

Before we dive in, it's important to note that routing in React is typically done with React Router Dom, an external library. Next.js, however, has its inbuilt routing capabilities.

Also, this article is written for the HNG internship. It is a three-month-long program where new developers can test themselves. They also offer career services such as recruitment and mentorship. More details here

Okay, let's explore these differences in detail.

Declarative vs File-Based Routing

The first major difference between routing in React and Next.js is how routing is handled.

React Routing

In React, we need to:

Add BrowserRouter to index.js
Declare the Routes component
Nest each Route component inside Routes
Add the intended component we want to route to, and the URL to each Route component

Here's an example:

// index.js
ReactDOM.render(
  <BrowserRouter>
    <App />
  </BrowserRouter>,
  document.getElementById('root')
);

// App.js
const App = () => {
  return (
    <div>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
        <Route path="/blog" element={<Blog />} />
        <Route path="/blog/:id" element={<BlogPost />} />
      </Routes>
    </div>
  );
};

export default App;

In summary, you have to define each route in React explicitly.

Next.js Routing

Next.js uses a different paradigm. You don't have to define routes explicitly due to Next's file-based routing, which uses the path of the file where your component is located as the URL of that route.

Using the same example as we used for React, our routes in Next.js might look like this:

my-next-app/
├── pages/
│   ├── index.js       // Corresponds to "/"
│   ├── about.js       // Corresponds to "/about"
│   ├── blog/
│   │   ├── index.js   // Corresponds to "/blog"
│   │   └── [id].js    // Corresponds to "/blog/[id]"
├── components/
│   ├── Home.js        // Component used in pages/index.js
│   ├── About.js       // Component used in pages/about.js
│   ├── Blog.js        // Component used in pages/blog/index.js
│   ├── BlogPost.js    // Component used in pages/blog/[id].js
└── public/
    └── ...

Next.js chose this file-based routing approach to simplify the routing process and make it more intuitive. It eliminates the need for a separate routing configuration, reducing boilerplate code and making the project structure more straightforward. This approach aligns well with Next.js's goal of providing a more opinionated and streamlined development experience.

In Next.js, we write our JSX inside About.js and then render it inside its route, about.js. This introduces an important design pattern when using Next.js - separating concerns:

// pages/about.js
import About from '../components/About';

export default function AboutPage() {
  return <About />;
}

// components/About.js
import React from 'react';

const About = () => {
  return <h1>About Page</h1>;
};

export default About;

In summary, Next.js routes are defined based on the component tree and the respective paths.

Dynamic Routing

The declarative approach of React Router and the file-based approach of Next.js impact how dynamic routes are built and executed in both frameworks.

Dynamic Routing in React

In React, you can define a dynamic route by adding a colon to the route URL:

// App.js
const App = () => {
  return (
    <div>
      <Routes>
        <Route path="/blog" element={<Blog />} />
        <Route path="/blog/:id" element={<BlogPost />} />
      </Routes>
    </div>
  );
};
export default App;

Each blog has a unique URL, so the path is /blog/whatever-the-title-of-the-blog-is.

Here's how you would use the dynamic parameter in React:

import { useParams } from 'react-router-dom';

const BlogPost = () => {
  const { id } = useParams();

  return (
    <div>
      <h1>Blog Post {id}</h1>
      {/* Use the id to fetch and display the blog post */}
    </div>
  );
};

export default BlogPost;

Dynamic Routing in Next.js

Next.js handles dynamic routing differently:

├── pages/
│   ├── blog/          // Corresponds to "/blog" 
│   │   └── [id].js    // Corresponds to "/blog/[id]"

Next.js indicates that a route should be dynamic by putting a variable inside square brackets. Here's how we might configure this:

import { useRouter } from 'next/router';

const BlogPost = () => {
  const router = useRouter(); // Get the router object
  const { id } = router.query; // Destructure to get the 'id' from the URL

  return (
    <div>
      <h1>Blog Post {id}</h1>
      {/* Use the id to fetch and display the blog post */}
    </div>
  );
};

export default BlogPost;

Here's what Next.js is doing under the hood:

Inside the [id].js file, we call the useRouter() method. This method reads [id].js file and saves it as an object. We save the result inside the router variable.
Then, we use the query function from useRouter to extract a specific part of the object that was generated. In this case, we collect the id.
Next.js will use that id collected as the URL for that route.

Let's see how we would link to this route:

import Link from 'next/link';

const BlogList = ({ blogs }) => {
  return (
    <div>
      <h1>Blog List</h1>
      <ul>
        {blogs.map((blog) => (
          <li key={blog.id}>
            <Link href={`/blog/${blog.id}`}>
              <a>{blog.title}</a>
            </Link>
          </li>
        ))}
      </ul>
    </div>
  );
};

export default BlogList;

We're taking the URL /blog/[id].js, and replacing it with /blog/${blog.id}. This way, whatever value blog.id holds becomes the URL, giving each individual blog its own unique route.

Conclusion

While both React (with React Router) and Next.js provide powerful routing capabilities, they approach it differently. React Router uses a more declarative style, while Next.js leverages file-based routing. Understanding these differences can help developers choose the right framework for their needs and use routing effectively in their applications.

A simple introduction to JavaScript promises

Armstrong Olusoji — Mon, 27 May 2024 11:37:00 +0000

Introduction

Modern web development requires asynchronicity. Sometimes, a function needs to run only if a prior function is successful. At other times, multiple tasks within an application must occur simultaneously. Functions that need to run simultaneously are asynchronous.

Programming languages, however, are not all equal. Java and the C family are multi-threaded, meaning they can handle asynchronous operations naturally. JavaScript, however, is a single-threaded language. Special functions are therefore needed to manage asynchronous operations in JavaScript. Async / Await and Promises are two such functions. This article will focus on Promises.

This article will cover the following topics:

Defining JavaScript Promises
Constructing a Promise
Handling the success or failure of a Promise
Chaining multiple Promises

To get the most out of this article, readers should understand the fundamentals of JavaScript.

What is a Promise?

A Promise is a JavaScript object that represents the outcome of an asynchronous operation. When you work with asynchronous tasks like network requests or file reading, you can use Promises to handle the result of those tasks.

A Promise isn't the function itself, nor is it the direct result of the function. Instead, it acts as a container for a future value, which can be either a successful result or a failure (error).

The state of a Promise reflects the progress of the asynchronous operation:

Pending (the operation is ongoing and hasn't completed yet)
Resolved: (the operation is succesful)
Rejected: (the operation has failed)

Please note that the failure of a Promise doesn't always indicate bad code. Failure can be due to external conditions not met, or explicit error handling within the code.

For example, the user of a digital library has picked a book that is not available. Based on the constructor, the promise may be rejected. The failure of this operation is due to low inventory, not bad code. Yet this condition must be explicitely stated in the promise constructor.

Constructing a promise object

The Promise constructor method uses what is known as an executor function. An executor function is simple a function that returns either a resolved, or a rejected value. In most cases, this function will return both values depending on the conditions set by the developer.

The syntax for constructing a promise is as follows:

const executorFunction = (resolve, reject) => {
    //function body

    if(condition){
        resolve('This promise is succesful')
    }
    else {
        reject('This promise has failed')
    }
}
const newPromise = new Promise(executorFunction)

We could also use the convention of nesting a promise constructor inside a regular function. Like so:

const regularFunction = (argument) => {
  return new Promise ((resolve, reject) => {
    if(condition){
        resolve('This promise is succesful')
    }
    else {
        reject('This promise has failed')
    }
  })
}

Let us break it down:

(resolve, reject): resolve and reject are functions that are built into the promise constructor. They handle cases of success, or failure
body: the executor function body
if, else: if a condition is met, resolve() is triggered. Otherwise, reject() is triggered.
new Promise(): a promise is an object, and needs to be instantiated.

Example: Check if a book is available

//Create a database of books

const books = {
  "Steve Jobs": {
    title: "Steve Jobs",
    author: "Walter Isaacson",
    quantityInStock: 5,
    libraryPointsRequired: 2,
  },
  "Elon Musk": {
    title: "Elon Musk",
    author: "Walter Isaacson",
    quantityInStock: 1,
    libraryPointsRequired: 2,
  },
  "Hard Drive": {
    title: "Hard Drive",
    author: "James Wallace",
    quantityInStock: 3,
    libraryPointsRequired: 2,
  },
  "The Innovators": {
    title: "The Innovators",
    author: "Walter Isaacson",
    quantityInStock: 4,
    libraryPointsRequired: 2,
  },
  "Einstein: His Life and Universe": {
    title: "Einstein: His Life and Universe",
    author: "Walter Isaacson",
    quantityInStock: 2,
    libraryPointsRequired: 2,
  },
  "The Code Breaker": {
    title: "The Code Breaker",
    author: "Walter Isaacson",
    quantityInStock: 1,
    libraryPointsRequired: 2,
  },
  "The Martian": {
    title: "The Martian",
    author: "Andy Weir",
    quantityInStock: 5,
    libraryPointsRequired: 2,
  },

  Artemis: {
    title: "Artemis",
    author: "Andy Weir",
    quantityInStock: 2,
    libraryPointsRequired: 2,
  },
};

// Object holding a user profile

const user = {
  name: "Armstrong Olusoji",
  bookShelf: [],
};

// Write a function that checks if a book is in stock

const verifyOrder = (orderObject) => {
  return new Promise((resolve, reject) => {
    let book = null;
    const title = orderObject.title;
    const quantity = orderObject.quantity;
    if (books.hasOwnProperty(title)) {
      book = books[title];
    }
    if (book.quantityInStock >= quantity) {
      console.log(`${book.title} by ${book.author} is in stock`);
      resolve(book);
    } else {
      console.log(`${book.title} by ${book.author} is not in stock`);
      reject(book);
    }
  });
};

Now, we can simply call verifyOrder, and depending on the availability of a book, it will either send a resolved value, or a reason for rejection.

But what happens after verifyOrder has run? Do we want to log the resolve/reject value to the console? Do we want to do something else? What do we do after a promise is resolved or rejected?

Handling success and failure with .then()

The resolve / reject value can be resolved simply by passing a callback function into .then()

Let us test this with our verifyOrder function:

const handleSuccess = (resolvedValue) => {
  console.log(resolvedValue);
};

const handleFailure = (rejectedValue) => {
  console.log(rejectedValue);
};

verifyorder("Hard Drive", 5).then(handleSuccess, handleFailure);

handleSuccess(): is a callback function takes a single argument resolvedValue. In case of success, this function logs the resolved value to the console.
handleFailure(): is a callback function that receives a single argument rejectedValue. In case of failure, this function logs logs the rejected value to the console.
.then(): receives two callback functions as triggered. The first argument is triggerd if the promise is successful. The second argument is triggered if the promise fails.
If verifyOrder succeeds, handleSuccess will execute. Otherwise, handleFailure will execute.

Please note that once you add .then() to any promise, the promise's resolved and rejected values are automatically passed to the corresponding callback function.

However, there are other ways to use the success/failure callback functions.

const handleSuccess = (resolvedValue) => {
  console.log(resolvedValue);
};

const handleFailure = (rejectedValue) => {
  console.log(rejectedValue);
};

checkAvailability("Hard Drive", 5).then(handleSuccess).then(handleFailure);

This code works the same way. The only difference is that rather than put both callback functions in a single .then(), we seperate the concerns. Like in the first method, the success handler needs to come first. But there is yet another way to achieve the same outcome.

const handleSuccess = (resolvedValue) => {
  console.log(resolvedValue);
};

const handleFailure = (rejectedValue) => {
  console.log(rejectedValue);
};

checkAvailability("Hard Drive", 5).then(handleSuccess).catch(handleFailure);

This method is similar to the second method. The only difference is that we use .catch() to handle failure rather than a second .then()

Either of these three methods will simply send the resolve / reject value from verifyOrder to the respective callback functions.

But what if, depending on the availability of a book, we want to trigger a new function? Let us talk about chaining promises.

Chaining Promises / Promise Composition

In the previous exercise, we created a promise named verifyOrder. This promise checks if the book a customer wants is in stock. If it is in stock, the promise is resolved, and the success handler is triggered. Otherwise, the failure handler will execute.

But what happens after that?

Well, if we verify that a book is available, we want to add that book to the user's bookshelf. But if it is not, we want to recommend other books from the same author.

Promise composition enables us to connect promises. In our example, a fulfilled verifyOrder promise will trigger the checkOut Promise. If checkOut is successful, the addToShelf promise will be triggered successfully. A rejected verifyOrder promise will trigger the recommendBook promise. Let us see this in practice.

First, we create a checkOut function to handle checkouttitle in. It should check the object order's libraryPoints. If there are enough library points, the promise should deduct the required points from libraryPoints, and then, title in that order to the user's bookShelf. Otherwise, it should be rejected.

const order = {
  title: "The Innovators",
  quantity: 3,
  libraryPoints: 10,
};

const checkOut = (book) => {
  return new Promise((resolve, reject) => {
    const requiredPoints = book.libraryPointsRequired;
    const title = book.title;
    const points = order.libraryPoints;

    if (requiredPoints <= points) {
      order.libraryPoints -= requiredPoints;
      console.log(
        `The transaction is successful, and your library card now has ${order.libraryPoints} points`
      );
      resolve(user.bookShelf.push(`${book.title} by ${book.author}`));
    } else {
      reject("You don't have enough points for this transaction");
    }
  });
};

Finally, we will add a new promise called recommendBook. If verifyOrder fails, recommendBook will highlight other books from the same author.

const recommendBook = (book) => {
  return new Promise((resolve) => {
    const authorToMatch = book.author; // Use the author from the provided book
    const recommendedBooks = [];

    for (const title in books) {
      const bookItem = books[title];
      if (bookItem.author === authorToMatch && title !== book.title) {
        recommendedBooks.push(bookItem.title);
      }
    }
    console.log(
      `We don't have the book you wanted, but here are some other books from the same author: ${recommendedBooks}`
    );
    resolve(recommendedBooks);
  });
};

Finally, let us chain all these newly created promises together.

verifyOrder(order)
  .then(checkOut)
  .then((updatedBookShelf) => {
    console.log(
      `Your book has been added to the bookShelf: ${updatedBookShelf}`
    );
  })
  .catch((error) => {
    console.error(`An error occurred: ${error}`);
  });

A breakdown of what is happening here is as follows:

We call verifyOrder with the argument order
If the verifyOrder promise resolves then checkOut should execute
If checkOut succeeds, we chain an anonymous function to log the value of return value of checkOut. Something to note here is that .then automatically appends the return value of the previous promise as an arguement of the current promise.
Finally, we use .catch() in case the promise fails at any point. Passing the 'error' argument will catch any error during the promise, and log it to the console. This could be a useful debugging tool!

Conclusion

Asynchronous operations are vital in web development. Not only do they improve performance, but they also help developers create logical flows for their functions to execute. Since JavaScript is a single-threaded language, we can build asynchronous operations with Promises.

Promises are simple to use. Creating one is as simple as using the 'new Promise' constructor. Since a promise is a function, we ought to add the arguments resolve, and reject. These arguments represent the return value of the promise if it fails or succeeds.

In the event of a success or a failure, we may want to trigger another function. We can use .then(() => success handler function), or .catch(() => failure handler function). In the spirit of asynchronous operations, these help us logically manage the flow of tasks.

Admittedly, promises have more features. However, discussing them would be out of the scope of this article. You can read more here

Your client-side is not secure without these 5 practices

Armstrong Olusoji — Fri, 24 May 2024 07:39:28 +0000

From HTML websites in the 1980s to progressive web apps in 2024, web development has come a long way. And as client-side capabilities have improved, so has the importance of security. We may get away with poor security on a static HTML page but modern websites store cookies, passwords, credit card information, and other data. As such, security for the client is more important than ever.

This article provides a high-level summary of client security. The article covers the following topics:

Input validation
User Authentication
User Authorization
Data protection
Secure communication

Each section has a description and a few techniques that you can implement. The article also offers a few code snippets in JavaScript. These code snippets are for demonstration purposes only.
Finally, I hope you enjoy reading this article. I certainly enjoyed writing it.

Input Validation

Input validation is the process of filtering what users input into an application. Essential for client-side security, input validation is required but more is needed.
Consider the following scenario:. Someone wants to attack your website with a virus. So they go on the 'contact us' form. They then input characters that the browser will interpret as code and execute. Now your website is executing code that you did not design. This leads to all sorts of strange behavior, including stolen user data.

Whitelisting vs Blacklisting

You could avoid all this by ensuring no malicious input enters your website. You could use any whitelisting technique. This means that you have a list of characters that the website allows. Anything else will be rejected. You could also use a blacklisting technique. A blacklist contains a list of characters that are NOT allowed. Generally, whitelisting is safer than blacklisting because blacklisting is more susceptible to filter evasion

Semantic and Syntactic Validity

Any good input validation technique should also ensure both syntax and semantic validity. syntax validity ensures that an input is in the correct form or type. E.g., The CVV code for a credit card must always be three digits. Semantic validity ensures that the imputed data follows the correct context or order. For example, the expiration date of a debit card should always be a future date.

Common input validation techniques

Now that you understand the basics of input validation, let us review some common techniques.

Built-in validation: involves the use of inbuilt HTML attributes such as required, pattern, type, min-length, max-length, pattern, and so on. Read more here

<!-- Requiring a field -->
<input type="text" name="username" required>

<!-- Setting a pattern for input -->
<input type="text" name="phone" pattern="[0-9]{3}-[0-9]{3}-[0-9]{4}">

<!-- Limiting input length -->
<input type="text" name="zipcode" minlength="5" maxlength="9">

Sanitization: involves cleaning up an input that contains suspicious characters. Read more here

// Code to remove HTML tags from input
function sanitizeInput(input) {
  return input.replace(/</g, '&lt;').replace(/>/g, '&gt;');
}

// Code to remove leading/trailing whitespace and limit to alphanumeric
function sanitizeUsername(username) {
  return username.trim().replace(/[^a-zA-Z0-9]/g, '');
}

Regular Expressions (REGEX): useful for imposing a pattern in which data must be input. Only data that matches the preset pattern will be accepted! Regex is typically used for zip code or password form fields. Here is an excellent blog about regular expressions

// Password validation (at least 8 chars, 1 uppercase, 1 number)
const passwordPattern = /^(?=.*[A-Z])(?=.*\d).{8,}$/;
function validatePassword(password) {
  return passwordPattern.test(password);
}

User Authentication

User authentication is verifying a user’s identity before giving them access to their account and everything associated with it. Authentication is useful for user experience. But more importantly, it is a security measure that ensures that sensitive data is accessed only by authorized parties.

User authentication is essential to web security. Without it, user accounts are vulnerable to cyber-attacks. Consider a website without 2-factor authentication. It is easy to hack a user's account on such a website. All an attacker has to do is guess the user's password. That is why it is important to utilize the knowledge factor, possession factor, and inherence factor.
The knowledge factor authentication is based on knowledge that only the user would have. Security questions and passwords are in this category. The possession factor, however, refers to authentication that requires physical devices owned by the user. A physical cryptocurrency wallet is an example here. Finally, consider the inherence factor for authentication. It has to do with biometrics such as fingerprints, facial recognition, etc.
Generally, though, most security on the client is based on the knowledge factor. It is unlikely that a website would request fingerprints for access. Nevertheless, user authentication techniques for the client are based on either of those factors.

Common authentication techniques:

Password-based authentication receives a password from a user in exchange for access. This is the most common form of user authentication/authorization. One issue with this approach is that weak passwords will be easily bypassed.
Multi-factor authentication (MFA) enforces several layers of authentication on users. E.g., in 2-factor authentication, you set a password and also receive a one-time passcode via SMS. The purpose of this extra layer is often to notify you of a potential hack on your account. Mixing the knowledge factor with the physical factor works here. For example, Gmail requires users to log in with a password and confirm the login on a device that they own!
Certificate Base Authority collaborates with a trusted authority to issue a unique certificate. e.g., the Microsoft Authenticator app is a trusted authority. The developer can use it to generate a unique code to authenticate a user. The user would then input the code to gain access.
Token-based authentication generates access tokens that give a user access to certain features. Tokens usually have a scope, i.e., they give restricted access to features. Tokens also expire. One example of this is the Spotify API Oauth sign-in. It allows third-party apps to make changes to users' accounts as long as an access token is part of the API call. First, the user gives the developer access to their account. Then Spotify sends the developer an access token. The developer then uses the token to perform actions within the scope of what the user has agreed to.

// Basic password authentication
function authenticateUser(username, password) {
  const user = database.findUser(username);
  if (user && user.password === password) {
    return true; // Authentication successful
  }
  return false; // Authentication failed
}

// 2-Factor Authentication with SMS code
function authenticate2FA(username, password, smsCode) {
  if (authenticateUser(username, password)) {
    if (verifyCode(username, smsCode)) {
      return true; // 2FA successful
    }
  }
  return false; // 2FA failed
}

User Authorization

User authorization is the conditional issuance of permissions to different kinds of users of a website. Simply put, authorization determines what privileges different clients have. Authorization filters users based on varying conditions and gives access accordingly. An important mental model for thinking about this is as follows:

Subject: Who is the user?
Resource: which object does the user want to access?
Action: Which actions is the user trying to perform with the resource he has access to?

Consider business enterprise resource management software. For a given business, there are finance, human resources (HR), and product dashboards. Naturally, the head of finance has access to the finance dashboard. The head of HR has access to the HR dashboard, and the head of product uses the product dashboard. Imagine that the HR manager needs some information on his department's budget. We could simply give him/her limited access to the finance dashboard. Many of the tools that you use as a developer already have these features. Figma, Google, and even Jira all give conditional access to different features.

Common user authorization techniques

Some user authorization methods are as follows:

Role-Based Access Control allows access to resources depending on the role of the user. For example, Google Docs has roles for editors, viewers, and commenters. Someone with the role of a commenter cannot access the features of an editor.
Attribute-Based Access Control filters different users based on their attributes. Consider a SAAS website with tiered pricing. Users either have access to premium features or not, depending on whether they have paid or not. One independent publisher on the internet noticed that excessive scrapping was affecting the performance of his website. So he put up a paywall to allow only paid users to access the content. This action improved the website's performance!
Privileged Access Management prevents regular users from accessing sensitive information. An excellent example of this is WordPress. WordPress websites are publicly accessible. Yet only the website administrators can make any changes to them.

// Role-based access control
function authorize(user, resource, action) {
  const role = user.role;
  const permissions = roles[role];
  const isAllowed = permissions.some(p =>
    p.resource === resource && p.actions.includes(action)
  );
  return isAllowed;
}

// Attribute-based access control
function authorizePaidContent(user, resource) {
  if (user.subscription === 'paid') {
    return true; // Allow paid users
  }
  return false; // Block non-paid users
}

Data Protection

Data protection is critical to client-side security. Modern web applications are complex. They also handle a lot of sensitive information. It is important to protect data for the following reasons:

Preventing Data Leakage: Data stored on the client side, such as user preferences, session tokens, and cached data, must be safeguarded to prevent unauthorized access or leakage.
Compliance Requirements: Adhering to data protection standards and regulations, such as GDPR, HIPAA, or CCPA, is essential to ensure the legal and ethical handling of user data.
Mitigating Security Risks: Data protection measures reduce the risk of data breaches, identity theft, and other security threats that exploit vulnerabilities in client-side data storage.

Techniques for Data Protection

Encryption: Encrypting sensitive data before storing it on the client side ensures that even if accessed by unauthorized parties, the data remains unreadable without the decryption key. To do this, Use strong encryption algorithms such as AES (Advanced Encryption Standard) for encrypting data at rest and TLS (Transport Layer Security) for encrypting data in transit.
Data Masking and Tokenization: Masking sensitive data elements or tokenizing them into non-sensitive equivalents reduces the exposure of actual data, enhancing privacy and security.
Use tokenization services or libraries to generate and manage tokens for sensitive data fields, such as credit card numbers or personally identifiable information (PII).
Regular Security Audits and Updates: Conduct regular security audits and updates of your client-side data protection mechanisms to identify and address vulnerabilities proactively. Stay informed about emerging security threats and best practices in data protection to continually improve your application's security posture.

By implementing these data protection techniques, web developers can enhance the security and privacy of client-side data, thereby fostering user trust and compliance with regulatory requirements.

Secure Communication

Secure communication is pivotal to safeguarding data integrity, confidentiality, and authenticity during transmission between clients and servers. Secure communication is important for the following reason:

Data Confidentiality: Encryption ensures that sensitive data exchanged between clients and servers remains confidential and unreadable to unauthorized entities.
Data Integrity: Secure communication protocols, such as HTTPS, prevent data tampering or modification during transmission, maintaining data integrity and trustworthiness.
Authentication and Identity Verification: Secure communication protocols enable mutual authentication between clients and servers, verifying the identities of both parties to prevent impersonation attacks.
Protection Against Eavesdropping: Encryption of data in transit mitigates the risk of eavesdropping or interception by malicious actors seeking to capture sensitive information.

Techniques for Secure Communication

HTTPS (Hypertext Transfer Protocol Secure):
- Utilize HTTPS to encrypt data exchanged between clients and servers, providing a secure communication channel over the Internet.
- Obtain and install SSL/TLS certificates from trusted certificate authorities to enable HTTPS on your web servers.
TLS (Transport Layer Security):
- Implement the latest TLS versions (e.g., TLS 1.2 or TLS 1.3) with strong cipher suites to secure communication channels and protect against known vulnerabilities.
- Configure server-side security settings, such as Perfect Forward Secrecy (PFS), to enhance the resilience of TLS encryption.
Certificate-based Authentication:
- Employ certificate-based authentication mechanisms, such as client SSL certificates, to verify the identities of clients and servers during SSL/TLS handshake.
- Maintain a secure certificate management process, including certificate issuance, revocation, and renewal, to prevent certificate-related security incidents.
Content Security Policies (CSP):
- Implement CSP headers to define and enforce security policies regarding permitted content sources, mitigating risks associated with XSS attacks and content injection vulnerabilities.
- Specify strict CSP directives, such as 'default-src 'self'', 'script-src 'nonce-hash'', and 'upgrade-insecure-requests', to enhance web application security.
Secure WebSockets:
- When using WebSockets for real-time communication, ensure WebSocket connections are secured with SSL/TLS encryption to protect data exchanged between clients and servers.
- Apply WebSocket security best practices, such as rate limiting, origin validation, and message validation, to prevent WebSocket-based attacks and abuse.
Secure File Transfers:
- For file uploads or downloads, employ secure protocols such as SFTP (SSH File Transfer Protocol) or HTTPS with multipart form data to encrypt file transfers and prevent unauthorized access.
- Implement server-side file validation and sanitization to mitigate risks associated with malicious file uploads, including malware or script injections.
Network Security Measures:
- Deploy network security measures, such as firewalls, intrusion detection/prevention systems (IDS/IPS), and secure VPNs (Virtual Private Networks), to protect against network-based attacks and unauthorized access attempts.
- Monitor network traffic and perform regular security audits to detect and respond to anomalous or suspicious activities affecting secure communication channels.

By adopting these secure communication techniques and best practices, web developers can establish resilient and trustworthy communication channels, ensuring the confidentiality, integrity, and authenticity of data exchanged between clients and servers.

Conclusion

Client security is essential to protecting user data and defending against cyberattacks. Here’s everything we covered in this article:
Input validation protects your website from SQL injections and other malicious input. User authentication and authorization are children of the same parent. Authentication ensures that only the owner or a user account can access it. Authorization creates permissions that limit or allow access to resources within a website. Finally, data protection is useful for securing the data that is stored on the client; while secure communication protects the data that travels between the server and the client.

Should I use a radio group or a checkbox?

Armstrong Olusoji — Mon, 22 Apr 2024 14:12:23 +0000

Selectors are important in software development. They are useful in forms, settings, and other features that require the user's input. Selectors, though, are not built equal. Different selectors have different jobs. Without a dedicated UX/UI designer, you may use a radio where you need a checkbox.

This article will cover radio groups and checkboxes. We will touch on their history and define them. Then, we discuss the ideal and unacceptable use cases for each selector. Two terms you will often see in this article are:

Mutually Exclusive: options that cannot occur at the same time
Mutually Inclusive: options that can occur at the same time.

Finally, this article shows you how to build these selectors with React and Material UI. These code blocks will cement the logic behind each of the selectors. For this portion of the article, you need the following prerequisite knowledge:

JavaScript fundamentals
React fundamentals

The Checkbox

The checkbox is a graphic component that helps a user choose from a list. The checkbox is based on skeuomorphism, a design system that models digital assets after real-life objects. The real-life object that the digital checkbox mirrors is the paper and pen list. See Fig 1:

Imagine you have to keep track of your chores at home. Have you washed the dishes? Check. Did you do the laundry? Check. Have you cooked for granny? Check. These are Boolean choices. The answer could only be 'yes' or 'no'. And this is the original kind of checkbox where choices are mutually exclusive.

But imagine a different non-linear question. How many tech stacks do you know? JavaScript, check. CSS, check. React, Check. Zustand, Check. Redux, learning. This makes things more interesting. The answer is not always binary. This creates a third category which you may know as 'maybe'. The technical term for this state is 'indeterminate'. And any checkbox with an indeterminate state is a Tri-State Checkbox.

Both the classic and the tri-state checkboxes are mutually exclusive. To pick one answer is to invalidate the other(s). But as checkboxes evolved, they became mutually inclusive. We started using them to provide a list of options where users can pick multiple. For example, what programming languages, frameworks, and libraries do you know? Pick as many as you like.

Here are more examples of checkbox use cases:

A job board user wants to pick all the job titles they are interested in.
A fashion e-commerce store allows users to pick the colors, and sizes they want for a pair of shoes.
A product manager wants to pick which team members have edit access to the Jira workspace.
A first-time Spotify user wants to pick their favorite music genres and artists

How to build a Checkbox Component with React and Material UI

In this mini-project, we create a checkbox to select some of our favorite colors.

import React, { useState } from "react";
import {
  FormGroup,
  Checkbox,
  Box,
  Stack,
  Typography,
  FormControlLabel,
} from "@mui/material";

export default function TestingCheckbox() {
  const [selectedColors, setSelectedColors] = useState([]);

  const colors = [
    { name: "Blue", code: "#2196F3" },
    { name: "Green", code: "#4CAF50" },
    { name: "Red", code: "#F44336" },
  ];

  const handleClick = (color) => {
    //check if color already exists
    if (selectedColors.some((c) => c.name === color.name)) {
      // if yes, remove it from the array
      setSelectedColors((prevSelectedColors) =>
        prevSelectedColors.filter((item) => item.name !== color.name)
      );
    } else {
      //otherwise add it to the array
      setSelectedColors((prevSelectedColors) => [...prevSelectedColors, color]);
    }
  };

Here’s how it works:

Import React, and useState
Import Form Group, Checkbox, and other MUI components for styling
Create a function named TestingCheckbox
Inside TestingCheckbox, create a state variable named selectedColors. SelectedColors is an array that will hold any color a user picks from the checkbox.
Create an array of colors
Create a function named handleClick. Handle click will do the following:
- Receive color as a variable
- Check the selectedColors array to see if color is already present. We do this using the .some() array method
- If color is already present in selectedColors, remove it using the .filter() array method.
- If color is not present in the selectedColors array add it using the spread operator

Next, we build the interface for the checkbox and attach the above logic to it. Here’s the code:

import React, { useState } from "react";
import {
  FormGroup,
  Checkbox,
  Box,
  Stack,
  Typography,
  FormControlLabel,
} from "@mui/material";

export default function TestingCheckbox() {
…
 …

  return (
    <>
      <FormGroup>
        {colors.map((color, idx) => (
          <FormControlLabel
            control={<Checkbox />}
            value={color}
            label={`${color.name}`}
            onChange={() => handleClick(color)}
          />
        ))}
      </FormGroup>
    </>
  );
}

Here’s how it works:

Use the FormGroup component from MUI.
Inside the FormGroup component, nest a FormControlLabel
Inside the FormControlLabel do the following:
- Add a control prop to decide how you want the form to be controlled. Since we are building a Checkbox, add the MUI Checkbox component.
- Add a value prop to determine what value the checkbox holds. In this case, we want the color object to be the value.
- Add a label prop to determine which text is rendered alongside the checkbox. We use the name of the color in this case.
- Add an onChange prop to determine what happens when the checkbox is checked or not. Let the prop value be a function that calls the handleClick function you created earlier. Pass color as the parameter.
Test the component by logging selectedColors to the console. Whatever you check will appear in the array. And whatever you uncheck will be removed from the array.

Look below for a gif of the expected behavior.

The Radio Group

A radio group is a collection of mutually exclusive options where selecting one deselects the others. You could also call it an option group. Also based on skeuomorphism, the radio group evolved from the buttons of car radios.

One way to visualize this is to imagine 2 buttons on a car radio. Once you click button-one, it sinks in and stays that way. But when you click button-two, it sinks in and button-one pops back up. It is impossible to select two buttons at the same time

One earliest adaptations of car radio buttons was in the BitRectEditor for Smalltalk. It was a 1975 digital sketch board that had several color palettes. You could only pick one color palette at a time. This principle has evolved into the 21st century in other forms. You should only use a radio group when only one option out of several can be true at a time. Some examples are as follows:

A survey field with the answers 'Strongly Agree, Agree, Disagree, Strongly Disagree'.
A form field asking users to pick their gender
A field allowing a user to pick one mode of transportation on Google Maps.
A page outlining the subscription plans and asking a user to pick one.

How to build a radio group in React and MaterialUI

Now, we build a mini project. This project is similar to the last one. But this time, we want a user to pick one color. Like the last example, we first build the handler function, then the interface. Here’s the code:

import React, { useState } from "react";
import {Radio, RadioGroup, FormControlLabel, FormControl, FormLabel } from "@mui/material";
export default function SampleRadioGroup() {
  const [favoriteAnimal, setFavoriteAnimal] = useState("");

  const handleRadioChange = (event) => {
    setFavoriteAnimal(event.target.value);
  };

To build the logic for the Radio group, do the following:

Import React
Import FormGroup, RadioGroup, and other related MUI components.
Create the SampleRadioGroup function. Inside the SampleRadioGroup function, do the following:
- Create a state variable that keeps track of the chosen favorite animal.
- Create a callback function that updates favoriteAnimal with the value of the future event. In this case, the event is when a clicks a radio button.

…
return (
<>
 <FormControl>
      <FormLabel id="favorite-animal-label">
        My favourite animal is a {favoriteAnimal && favoriteAnimal}
      </FormLabel>
      <RadioGroup
        aria-labelledby="favorite-animal-label"
        defaultValue=""
        name="favorite-animal-group"
        value={favoriteAnimal}
        onChange={handleRadioChange}
      >
        <FormControlLabel value="Cat" control={<Radio />} label="Cat" />
        <FormControlLabel value="Dog" control={<Radio />} label="Dog" />
        <FormControlLabel
          value="Elephant"
          control={<Radio />}
          label="Elephant"
        />
      </RadioGroup>
    </FormControl>
  );
</>  
)
}

Here’s how it works:
Inside the return statement, do the following:

Add a FormControl component.
Nest a FormLabel component inside the FormControl. This serves as the title for the radio group.
After FormLabel add a RadioGroup component.
Inside RadioGroup use the following props:
- Set defaultValue as an empty string
- Set the value prop to favoriteAnimal. This way, whatever the favouriteAnimal state variable contains will automatically become the value/choice of the radio group.
- Set the onChange prop to handleRadioChange. This way, any radio button clicked within the radio group will trigger the callback function, handset the state of favoriteAnimal.
Finally, add a FormControlLabel for each animal. Use the following props:
- Set Value to the animal’s name
- Set the control type to an MUI Radio component
- Set the label to the animal’s name.
Test the Radio group by clicking on any animal. The title should read ‘My favorite animal is (whatever animal you pick)’. See below for a gif of the expected behavior

Conclusion

Picking the right selector is crucial to the user experience. As a rule of thumb, radio groups are useful when a user can only pick one of the options. Checkboxes are useful when a user can pick one, or multiple options from a list. Since these selectors are all based on real-life objects, you can imagine how you would use these selectors in the real world.

9 differences between IndexedDB and LocalStorage

Armstrong Olusoji — Mon, 22 Apr 2024 10:47:37 +0000

IndexedDB (IDB) and LocalStorage(LS) are tools for storing data on the client side. They can save cookies, sessions, and other data. This, however, is where the similarities end. IDB and LS work in different ways and often within different scopes. This article aims to provide a comparison that covers the following points:

Asynchonsity
Possible data structures
Versioning and data migration
Error handling
Storage size
Ease of use
Cross-platform compatibility
Security
Development tools and packages
Ideal use cases and examples

Asynchronicity

Asynchronous operations are crucial when dealing with data. For example, a chat app needs to retrieve the chat history data of a user, while listening for new messages. These are two different operations. Executing them on a queue would slow things down.
If you used local storage in the above example, you would settle for a queue. But with IndexedDB, you could run data operations concurrently with other functions. This is because IndexedDB can work through web workers. Web workers allow developers to execute scripts in separate threads. Thus, IndexedDB can perform its operations without disrupting the main thread. This is not possible with local storage.

Visualize this process in the image below:

Supported Data Structures

IndexedDB and Local Storage both store data as key-value pairs. This means that related data is identified with a key and saved as a value. For example, a drawer that stores socks would have a key titled ‘socks’. The value would then be all the socks that are stored inside that key.

While IndexedDb and LocalStorage store data in key-value pairs, they don't do it the same way. This is because LocalStorage only accepts strings as the value. IndexedDB, however, allows for strings, arrays, objects, and nested data. IndexedDB also allows you to nest key-value pairs inside parent key-value pairs.
The implication of these differences are two-fold:

indexedDB can handle complex data, but localStorage can not.
indexedDB allows for robust querying of the database, while localStorage does not.

Here’s localStorage storing an object, but converting it to a string first. Then retrieve it by converting it from a string to an object.



const user = {
  name: 'Jane Smith',
  age: 30,
  email: 'jane@example.com'
};
localStorage.setItem('user', JSON.stringify(user));

// Retrieving values
const name = localStorage.getItem('name'); // 'John Doe'
const userObj = JSON.parse(localStorage.getItem('user')); // { name: 'Jane Smith', age: 30, email: 'jane@example.com' }

Here is indexedDB storing a string, a nested object, and an array directly.



// Opening an IndexedDB database
const request = window.indexedDB.open('mydatabase', 1);

request.onupgradeneeded = (event) => {
  const db = event.target.result;

  // Creating an object store (similar to a table)
  const userStore = db.createObjectStore('users', { keyPath: 'id' });

  // Storing a string value
  userStore.put({ id: 1, name: 'John Doe' });

  // Storing an array
  userStore.put({ id: 2, emails: ['john@example.com', 'johnny@example.com'] });

  // Storing a nested object
  userStore.put({
    id: 3,
    profile: {
      name: 'Jane Smith',
      age: 30,
      address: {
        street: '123 Main St',
        city: 'Anytown',
        state: 'CA'
      }
    }
  });
};

request.onsuccess = (event) => {
  const db = event.target.result;
  const transaction = db.transaction(['users'], 'readonly');
  const userStore = transaction.objectStore('users');

  // Querying the database
  const request = userStore.get(3);
  request.onsuccess = () => {
    console.log(request.result.profile.address.city); // 'Anytown'
  };
};

Versioning and Data Migration

Versioning and data migration refer to the evolution of data in a code base. For example, version 1 of a user database could have the following schema:



User: {
Name: 'Paul Graham',
Age: '59'
}

Suppose you add a new feature that requires displaying the occupation of a user You would have to create version 2 as follows:



User: {
Name: 'Paul Graham',
Age: '59',
Occupation: 'Computer Scientist'
}

Something else happens in the above code. The existing data from version 1 has been migrated to version 2. Otherwise, version 2 would not have the same name and age.

The above code snippets are pseudocode, but they accurately represent data versioning and migration. More important though, is that with local storage, these things must be done manually. indexedDB, however, automates the process of data versioning and migration. For this reason, data integrity is higher when using IndexedDB than with localStorage.

Error handling

Both IndexedDB and local storage have their respective mechanisms for error handling.
Since IndexedDB is asynchronous, it uses promises and event listeners for error handling. For every indexedDB transaction, there are built-in resolved/rejected alerts. Here are some examples:

You request to open a database. IndexedDB’s IDBRequest interface shows you the error or success status of that transaction. IDBRequest works well for several kinds of transactions in IndexedDB
You have made a request. IndexedDB allows you to handle success with the event handles onsuccess(), and onerror(). This allows you to chain each request with functions that handle specific edge cases.

LocalStorage is synchronous and supports two major methods for error handling

Try - Catch blocks
If - else statements
Return values

Try-catch blocks are used in LocalStorage to log errors like QuotaExceededError. If - else statements also work well with localStorage. For example, while using the .getItem() method to retrieve an item, you could do:



 pseudo

if (storage.getItem())

{

 return x 

}

else {

return y 

}

Storage Size and eviction criteria

Another major difference between IndexedDB and LocalStorage is storage size. For localStorage, storage capacity is a fixed 10 MB.

IndexedDB, however, has no fixed capacity. This is because IndexedDB’s capacity depends on the available disk space in the user’s device. As a result, IndexedDB typically has storage space of 1GB, or 60% of the remaining disk space. This is a double-edged sword, as performance will differ for different users.

It is also important to note that IndexedDB and LocalStorage have eviction criteria. Eviction criteria refer to situations in which the data is deleted. Some of these criteria include the following:

Browser-specific policies for storage management impact eviction. For example, Chrome and Firefox use a Least Recently Used (LRU) policy. This means that they delete data when disk space is low.
Criteria set by the developer can also impact eviction. For example, a developer could add an expiration date that triggers the deletion of some data.
User actions can also trigger eviction. A user can delete their data from your site when they clear cookies and other browser data.

These three criteria are consistent for both LocalStorage and IndexedDB.

Ease of use

IndexedDB’s features make it more complex to use than local storage. IndexedDB's learning curve is steep due to its ability to process complex data structures. Code verbosity, error handling, and asynchronous operations are also issues.

LocalStorage has no such issues. The simplicity of its functionality means that you can learn and use it in 20 minutes or less. Here, only strings are used. Asynchonsity is not a factor here either, so your code will follow the main thread. This all contributes to simple, and less verbose code.

Cross-platform compatibility

They are both for the web, so they are not supported for native development. On the web, local storage shines as it has excellent support across all browsers. indexedDb is also well supported, but different browsers have bugs across different browsers. Here’s a forum conversation about some indexedDB bugs in Safari and Firefox.

Security

One of the most important security features for databases on the web is the same origin policy (SOP). It is a safeguard that ensures that a website can only run scripts from its domain. SOP implies that external sources cannot query your database, or run scripts that impact your website. This is useful to prevent cross-site scripting (XSS) attacks. IndexedDB and localStorage both use SOP, but that does not make them invincible. It is prudent for a developer to encrypt any data before storing it in indexedDB or localStorage.

Frameworks and developer support

There is one way around IndexedDB's complexity. That is Dexie.js, a lightweight framework that makes it easier to use IndexedDB. You can also use localForage, a JavaScript library for offline storage. It works as a wrapper for both indexedDB and localStorage. LocalForage was designed to improve the offline experience of web apps.

Conclusion

LocalStorage and IndexedDb are both client-side storage tools. So let’s go over everything we’ve discussed.

IndexedDb is asynchronous, while LocalStorage is not. This could impact performance
Data migration and versioning are also built into IndexedDB, unlike localStorage, where things are more manual.
LocalStorage is easier to use, while IndexedDB is more complex.
Both tools have the same level of browser support, with local storage being more consistent.
In terms of security, they both use the Same Origin Policy. However, developers should encrypt any data stored on the client.
LocalStorage is simple enough that it doesn’t need frameworks. But IndexedDB is easier to use with Dexie JS. LocalForage, however, works to improve the offline experience of web apps and works with both localStorage and IndexedDB.
Local storage uses try-catch blocks and if-else statements to handle errors. IndexedDB uses event handlers and in-built error handling.
LoalStorage can only store strings, while IndexedDB can store strings, arrays, objects, and nested objects.
Local storage has a storage capacity of 10 MB. But IndexedDB could have potentially limitless storage, depending on the free disk space of the user’s device.

With these nine points of comparison, you know enough to choose between IndexedDB and localStorage.

How to build a complex layout with Material UI

Armstrong Olusoji — Wed, 10 Apr 2024 22:37:11 +0000

Many developers assume that Material UI (MUI) cannot build complex layouts. But this is far from true. Building complex layouts with MUI involves mapping the page and using the right elements. To that effect, MUI provides layout components such as Grid. It also allows the use of custom CSS.

This article will attempt to recreate a complex layout with MUI and custom CSS. It reads like a tutorial, but it is not. It is more like a mental model for combining MUI layout components with custom CSS. As you follow the code in your own IDE, feel free to experiment with your solutions.

Some of the MUI layout components we will use are as follows:

Grid
Box
Stack

In this article, you will recreate the following layout:

As you follow along, please experiment with other features from the official MUI documentation. If you have any interesting insights, please share them in the comments.

Setting the Canvas

Here we set the canvas for the layout. Here’s the code:



import React from "react";
import { Grid } from "@mui/material";
export default function ComplexLayout() {
  return (
    {/* Main div for the entire page */}
<div
  className="body"
  style={{
    padding: "10px", // Adding padding to the div
    height: "100vh", // Setting the height of the div to full viewport height
    backgroundColor: "#212121", // Setting the background color of the div
  }}
>
  {/* Grid container with items in a row */}
  <Grid container direction={"row"} spacing={3} sx={{ padding: 5 }}>
    {/* Grid item for the slideshow, takes 3 columns on large screens and extra-large screens */}
    <Grid className="side-bar-container" item lg={3} xl={3}></Grid>
    {/* Grid item for the music player, takes 9 columns on large screens and extra-large screens */}
    <Grid className="main-content-container" item lg={9} xl={9}></Grid>
  </Grid>
</div>;
  );
}

Create a div (body) as the canvas for the page. Set its background color using the style prop. The style prop is used in MUI to add custom CSS to non-MUI components. If div was a MUI component, replace style with sx.
Let the body's height fill the entire screen by, setting its height to 100vh (viewport height).
Inside the body, create a Grid container and arrange its items in a row.
Let the Grid container have grid items. The items are side-bar-container and main-content-container.
Set the width of both grid items using breakpoints:
- side-bar-container: covers three grid columns on large screens.
- main-content-container: covers nine grid columns on large screens.

Building side-bar-container

Here's the code for side-bar-container:



<Grid className="side-bar-container" item lg={3} xl={3}>
  {/* Sidebar container with a black background */}
  <Box
    sx={{
      backgroundColor: "#000000",
      height: "100%",
      display: "flex",
      justifyContent: "center",
    }}
  >
    {/* Box inside the sidebar container */}
    <Stack spacing={2} sx={{ margin: "20px" }}>
      {/* Image placeholder */}
      <img
        src={imageplaceholder}
        style={{ objectFit: "contain", width: "100%" }}
      />
      {/* Heading text */}
      <Typography variant={"h5"} sx={{ color: "white" }}>
        dolor sed viverra ipsum nunc aliquet
      </Typography>
      {/* Button for reading more */}
      <Button variant={"text"} sx={{ justifyContent: "flex-start" }}>
        Read more
      </Button>
    </Stack>
  </Box>
</Grid>

Create a Box component:
- Set its height to 100% of its parent component. Since there is no explicit height for side-bar-container, the Box gets its context from the body's height which is '100vh'. Hence this Box height 100% fills the entire length of the body. Furthermore, MUI Grid items and containers derive their size from the content inside them. This means that side-bar-container will adjust its height to the Box container.
- Set Box's display to Flex so that Box becomes the context for its nested items.
- Justify the items inside it to the center.
Nest a Stack component inside the Box.
- Set the margin for Stack to create some separation between it and Box.
- Set the space between the stack items.
Inside the Stack, let the image be contained. Let the image also take 100% of the Stack's width
The MUI Button goes to the center of the parent component by default. Change that with justifyContent

By now, the page should look like this:

That does it for side-bar-container. Up next, main-content-container.

Building main-content-container

The main content container is a bit more tricky. We need to add the following aspects:

A large product image
A product description page
A color palette stacked on one another So far the document structure is as follows:



<div className='body'>
  <Grid container>
    <Grid item className='side-bar-container'> </Grid>
    <Grid item className='main-content-container'> </Grid>
  </Grid>
</div>

The body has a grid container inside it. The grid container has two grid items. Namely side-bar-content, and main-content-container. You have built side-bar-content. Now you will build main-content-container. Here’s its structure:



<Grid className="main-content-container" item lg={9} xl={9}>
  <Grid container spacing={3}>
    <Grid item className="content-box"></Grid>
    <Grid item className="colorlist" sx={{ overflow: "hidden" }}></Grid>
  </Grid>
</Grid>

Here is the text formatted in markdown:

Code explanation:

Inside main-content-container, nest a Grid container. In MUI, nesting grid containers into grid items allow us to build complex layouts. Each nested grid container is limited to the dimensions of its immediate parent.
Inside the grid container, create two grid items.
The grid items are content-box and color-list.
Building content-box
content-box has two sections. Here's the code structure:



<Grid item className="content-box">
  <Grid container spacing={3}>
    <Grid item className={"content-box-child-1"} lg={6}>
      <img src={imageplaceholder} style={{ height: "100%", width: "100%" }} />
    </Grid>
    <Grid item className={"content-box-child-2"} lg={6}>
      <Card
        sx={{
          backgroundColor: "#000000",
          height: "100%",
          borderRadius: "0",
        }}
      >
        <Stack spacing={2}>
          <CardContent>
            <Typography variant={"p"} sx={{ color: "white" }}>
              Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
              eiusmod tempor incididunt ut labore et dolore magna aliqua.
              Volutpat commodo sed egestas egestas. A cras semper auctor neque
              vitae tempus quam pellentesque nec. Quisque id diam vel quam
              elementum pulvinar etiam non. Porta non pulvinar neque laoreet
              suspendisse. Ultrices mi tempus imperdiet nulla.
            </Typography>
          </CardContent>
          {productList.map((product) => {
            return (
              <>
                <Box
                  border={3}
                  sx={{
                    backgroundColor: "#222222",
                  }}
                >
                  <Stack
                    direction={"row"}
                    alignItems={"center"}
                    justifyContent={"space-between"}
                  >
                    <Typography
                      sx={{ color: "white" }}
                    >{`${product.name}`}</Typography>
                    <Button>Add to cart</Button>
                  </Stack>
                </Box>
              </>
            );
          })}
        </Stack>
      </Card>
    </Grid>
  </Grid>
</Grid>

Code explanation:

Nest a Grid container inside content box.
Create two grid items inside the grid container. These items are content-box-child-1 and content-box-child-2
For content-box-child-1, do the following:
- Set the width to '6' grid columns on large screens. Hence, content-box-child-1 will take half the width of its parent container, main-content-container.
- Add an image. Let it fill the entire width and length of content-box-child-1.
For content-box-child-2, do the following:
- Set the width to '6' grid columns on large screens. Hence, content-box-child-2 will take half the width of its parent container, main-content-container.
- Create a card component inside content-box-child-2.
- Set the height of the card to fill the entire length of content-box-child-2.
- MUI cards have a preset border-radius. Set it to zero to overwrite the default.
- Inside the card, create a stack. Inside Stack do the following:
- Create CardContent.
- Add Typography to CardContent loop through an array.
- Render the array as follows: For each array item, create a Box component with a border of 2.
  - Inside the box, stack the name of the product and a button. Let the stack items be arranged in a row. Then do the following:
  - Justify each array item to have some space between them.
  - Align the items to the center.

By now, the layout should look like this:

Note: You set the height for the items in _content-box-child-1_ and _content-box-child-2_ to 100% of the grid item. Since these are the only Grid items in main-content-container, they will span the length of the entire page. But something interesting happens when we add another grid item to _main-content-container_'s main axis (vertical).

The 100% height content for the items in _content-box-child-1_ and _content-box-child-2_ changes context from main-content-container to just the grid item that holds that content.

Therefore, the 100% height will only be within the grid item. main-content-container will then expand its height to accommodate a new grid item along its main axis. This changes the layout of the entire page.

Building `color-list`

This is the second grid item inside _main-content-container_. Here's the code:



<Grid item className="color-list" sx={{ overflow: "hidden" }}>
  <Stack direction={"row"} spacing={-13}>
    {colorList.map((color) => {
      return (
        <Box
          sx={{
            width: "150px",
            height: "150px",
            backgroundColor: color,
          }}
        >
          {" "}
        </Box>
      );
    })}
  </Stack>
</Grid>

Code explanation:

Inside color-list create a Stack (not Tony Stark) component. 2.Since we have an array of over 20 colored boxes, set Stack's overflow to hidden.
Stack the images in a row
Add negative spacing, so each color box overlaps the color box to its left.
For each array item, do the following:
- Create a Box.
- Set a fixed height
- Set a fixed width
- Set the background color

The layout should look like this:

Conclusion:

MUI layout components such as Grid, Stack, and Box are just ways that MUI can help.
There are other components not used in this article. Please refer to the official documentation.

Furthermore, MUI allows developers to use custom CSS when necessary. This article demonstrates MUI's flexibility by using CSS 'flex display'. You can also use CSS features such as 'absolute' or 'Z-index'.

But beyond MUI's flexibility, this article provides a way to think about layouts. The major principle at play here is to group related content into containers. This principle is possible because of MUI's ability to use Grid components, Grid items, and Stacks as both parent and children. This idea offers the least path to resistance.

Finally, please do your experiments with MUI. For example, this article only uses the Large breakpoint. Hence, this design is not responsive on small and medium screens. Perhaps that is one way for you to test your newfound knowledge.

DEV Community: Armstrong Olusoji

How React19 optimizes rendering

Streamlining Asynchronous Operations with Actions

Testing a Form Action

Testing useFormStatus

Testing useActionState()

useOptimistic

The React Compiler

Server Components

Leading up to Server Components

How Server Components are an upgrade

Conclusion

How React19 optimizes rendering

Streamlining Asynchronous Operations with Actions

Testing a Form Action

Testing useFormStatus

Testing useActionState()

useOptimistic

The React Compiler

Server Components

Leading up to Server Components

How Server Components are an upgrade

Conclusion

5 crucial facts about React Rendering

What triggers a render in react?

Diffing and Reconciliation

Parent, Child, and Expensive Components

Mitigating Unnecessary Re-Renders

React.memo:

PureComponent:

useMemo:

useCallback:

shouldComponentUpdate:

Moving State Down:

Moving Content Up:

State as a snapshot

Pure functions and side effects

Conclusion

How Next router handles routing differently from React Router Dom

Declarative vs File-Based Routing

React Routing

Next.js Routing

Dynamic Routing

Dynamic Routing in React

Dynamic Routing in Next.js

Conclusion

A simple introduction to JavaScript promises

Introduction

What is a Promise?

Constructing a promise object

Example: Check if a book is available

Handling success and failure with .then()

Chaining Promises / Promise Composition

Conclusion

Your client-side is not secure without these 5 practices

Input Validation

Whitelisting vs Blacklisting

Semantic and Syntactic Validity

Common input validation techniques

User Authentication

Common authentication techniques:

User Authorization

Common user authorization techniques

Data Protection

Techniques for Data Protection

Secure Communication

Techniques for Secure Communication

Conclusion

Should I use a radio group or a checkbox?

The Checkbox

How to build a Checkbox Component with React and Material UI

The Radio Group

How to build a radio group in React and MaterialUI

Conclusion

9 differences between IndexedDB and LocalStorage

Asynchronicity

Supported Data Structures

Versioning and Data Migration

Error handling

Storage Size and eviction criteria

Testing `useActionState()`

Testing `useActionState()`

Building `color-list`