
In React applications, performance isn’t a huge consideration when the app is small and lightweight. 

However, when you start to scale the amount of data, routes, and API calls - the smallest inefficiencies are quickly magnified. 

One passion of mine is finding and fixing these inefficiencies. My brain sees it like a puzzle. The before and after is always my favorite part.

Let's see a few real-world scenarios where performance bottlenecks were identified and mitigated through strategic refactoring.

## Case 1: Unnecessary Rerenders

A significant challenge in optimizing React applications is managing unnecessary re-renders, which can degrade performance, especially in large-scale apps. A key factor contributing to this issue was the insufficient use of optimization techniques compatible with React's functional component paradigm.

Take a look at this code:

```jsx
function DataDisplay({ data }) {
	const [data, setData] = useState([]);
	  useEffect(() => {
	    // Fetch data from an API and update state
	  }, []);
  return (
    <>
	<select>
 	  <option value=1>1</option>
	  <option value=1>1</option>
  	  <option value=1>1</option>
      	</select>
      {data.map((item, index) => (
        <div key={index}>{item}</div>
      ))}
    </>
  );
}
```

In this simple component, the `DataDisplay` function receives a `data` prop and maps over it to generate some JSX, in addition to a ‘select’ input.

First, anytime the `select` option changes, the entire component will re-render. It would be better to move the [`data.map`](http://data.map) function to its own component such as `<DataList />`.

Second, the API call is a potential performance bottleneck. We’ve done a good job passing the empty array as the second argument of `useEffect`, so it will only run on the initial render.

However, if the `data` prop changes frequently, or if the array is large, this component will still re-render quite often.

We can do better.

If we know that the data prop will not change often, we can memoize it. Thus, anytime the component renders, it will render the cached version rather than mapping over the data again.

```jsx
const DataList = React.memo(({ data }) => {
  return data.map((item, index) => <div key={index}>{item}</div>);
});

function DataDisplay({ data }) {
  const [data, setData] = useState([]);
  useEffect(() => {
    // Fetch data from an API and update state
  }, []);
  return (
    <>
      <select>
        <option value=1>1</option>
        <option value=2>2</option>
        <option value=3>3</option>
      </select>
      <DataList data={data} />
    </>
  );
}

```

Using **`React.memo`** for functional components prevents unnecessary rerenders if the props and state have not changed. 

In the actual application, the refactoring process was mostly just doing this analysis for many components.

It required a detailed examination of the application's state management practices and an update to the components to use **`React.memo`** and **`useEffect`** efficiently. 

Know how to use useEffect, React.memo, and refactoring components to isolate expensive renders, is totally worth the effort. While it may take time at first, the performance wins are significant.

## Case 2: Inefficient Data Fetching

In another case, a React application was experiencing slow load times due to inefficient data fetching. The application was making multiple API calls to fetch the same data, leading to unnecessary network traffic and slow response times.

Before:

```jsx
// Initial code
function DataFetcher({ id }) {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchData(id)
      .then(response => setData(response.data))
      .catch(error => console.error(error));
  }, [id]);

  return data ? <div>{data}</div> : null;
}

// Usage in multiple components
function Component1() {
  return <DataFetcher id={1} />;
}

function Component2() {
  return <DataFetcher id={1} />;
}

```

In the above example, both `Component1` and `Component2` are fetching the same data independently. This data could have been fetched once and shared between both components, reducing the number of API calls.

The inefficiency was traced back to the architecture of the application. The application was structured in such a way that multiple components were independently fetching the same data, instead of sharing the data between components.

The solution involved restructuring the application to utilize a central state management system. This allowed the application to fetch data once and then share it among all the components that needed it. This architectural change resulted in a significant reduction in network traffic and improved the application's load times.

Using the above example, this looked like:

After:

```jsx
// Updated code
const DataContext = React.createContext(null);

function DataProvider({ id, children }) {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchData(id)
      .then(response => setData(response.data))
      .catch(error => console.error(error));
  }, [id]);

  return (
    <DataContext.Provider value={data}>
      {children}
    </DataContext.Provider>
  );
}

// Usage in multiple components
function Component1() {
  const data = useContext(DataContext);
  return data ? <div>{data}</div> : null;
}

function Component2() {
  const data = useContext(DataContext);
  return data ? <div>{data}</div> : null;
}

// Parent component
function ParentComponent() {
  return (
    <DataProvider id={1}>
      <Component1 />
      <Component2 />
    </DataProvider>
  );
}
```

Here, a new context `DataContext` is created and used to share the fetched data between its children, including `Component1` and `Component2`. The `DataProvider` component fetches the data and provides it to its children through the context. 

The data is fetched only once and then shared between components. This reduces network traffic and load times.

At first glance, this is a less elegant solution. However, the win comes at scale. Component1 and 2 are huge trees that extend across much of the application. Sharing already-fetched data rather than fetching it again is well worth the time spent refactoring.

Context API is also a good answer to [excessive prop drilling](https://dev.to/codeofrelevancy/what-is-prop-drilling-in-react-3kol).

## Case 3: Inefficient Rendering Due to Large Lists

Another common scenario in React applications is inefficient rendering due to handling large lists. 

When components need to render a large amount of data at once, it can lead to sluggish performance and slow response times.

In one case, a React application was experiencing performance issues while rendering a large list of data. 

### **Initial Approach (Inefficient Rendering)**

Initially, we have a React component that renders a large list of items. Here's a simple example without virtualization:

```jsx
import React from 'react';

function LargeList({ items }) {
  return (
    <ul>
      {items.map(item => (
        <li key={item.id}>{item.content}</li>
      ))}
    </ul>
  );
}
```

The solution involved implementing virtualization by using libraries such as `react-window` or `react-virtualized`. Virtualization allows React to render only what's visible on the screen, drastically reducing the number of components that need to be rendered at once.

Using the library `react-window`, the code above now becomes:

```jsx
import React from 'react';
import { FixedSizeList as List } from 'react-window';

function Row({ index, style, data }) {
  return (
    <div style={style} key={data[index].id}>
      {data[index].content}
    </div>
  );
}

function LargeList({ items }) {
  return (
    <List
      height={500} // Adjust based on the available height for your list
      itemCount={items.length}
      itemSize={35} // Adjust based on the height of each row/item
      width="100%" // Adjust or make responsive based on your layout
      itemData={items} // Data to be passed to each row
    >
      {Row}
    </List>
  );
}
```

With virtualization implemented, the application experienced a significant improvement in performance. 

In this solution, **`FixedSizeList`** is used to create a virtualized list where only the visible rows are rendered. The **`Row`** component renders each row's content, which receives the item's data as props along with a **`style`** object that must be applied for correct positioning and rendering.

Virtualization isn’t for every use case. But in this application, it was the right fit and made a significant difference.


Case Studies: Refactoring for Performance in React


Let’s take a quick look at two ways to add authentication in your react project. 

These two ways are simple and performant, and are both good starting points if you haven’t used an Auth solution before.

There are many tools available but the two we will be looking at today are JSONWebToken (JWT) and Clerk.js.

# JWT

To implement JWT, we will first install the *jsonwebtoken* package via npm/yarn. Next, you generate a token on the server-side during user login, then send and store this token on the client-side. This token is then included in the header of any subsequent requests to validate user access.

Let’s take a look step by step.

First, run `npm i jsonwebtoken` or `yarn add jsonwebtoken` to install the package. Then import it into your backend file where the login route is defined.

The first thing we will do is generate a token during login. To do this, require `jsonwebtoken` into the file and use the `jwt.sign` method to create a token.

```jsx
const jwt = require('jsonwebtoken');

// user login route
app.post('/login', (req, res) => {
  const user = { id: 1 }; // this should be the user data retrieved from the database

  jwt.sign({ user }, 'your_secret_key', (err, token) => {
    res.json({ token });
  });
});

```

You will want to store this token on the client-side, and include it in the Authorization header of each request. 

Next we will verify the token within our middleware to ensure it is valid and has not expired, granting or denying access based on the result.

```jsx
// middleware
app.use((req, res, next) => {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (token == null) return res.sendStatus(401);

  jwt.verify(token, 'your_secret_key', (err, user) => {
    if (err) return res.sendStatus(403);
    req.user = user;

    next();
  });
});
```

Alternatively, you can use jwt.verify within specific routes to do custom auth handling within each route.

But let’s say you want to focus on frontend components rather than writing backend routes. If your app is primarily frontend-focused, then a solution that abstracts away most of the backend auth work might be the solution.

Let’s look at one of my favorite solutions: Clerk.js.

# Clerk.js

Clerk.js is a user management and authentication serviceIt provides a fully managed user database, handles sign-up and login forms, session management, and more.

Because Clerk is a hosted solution, they do have paid plan tiers. However, the free tier is generous and more than enough to get started and learn the platform.

## Setup

You’ll first want to create an account on the Clerk website and create a new project. You’ll be given two auto-generated keys to include in your .env file. The setup instructions are easy to follow.

Then, run npm i or yarn add as usual.

Clerk provides many components that are simple and easy to use. You just import them and add them into your JSX.

For example, here’s a user account page I created recently, using SignedIn / SignedOut checks to conditionally display different components:

```jsx
import { SignedIn, SignedOut, UserProfile } from "@clerk/nextjs";

export default function Page() {
    return (
      <>
        <SignedIn>
          <UserProfile />
        </SignedIn>
        <SignedOut>
          <p className="mb-4">Log in here:</p>
          <Link href="/login">Log In</Link>
        </SignedOut>
      </>
    );
}
```

Pretty cool, right?

# Summary

JWT and Clerk.js are just two of many tools available for adding authentication to your React project. 

Hopefully this article gives you an idea of the differences between a custom JWT solution and a hosted, abstracted solution like Clerk.

Have a better way of doing Auth in your React project? Reach out and let me know what you use.

Authentication in React: Two Approaches


This project was an exciting one as it’s not just a frontend project, but an entire full-stack web application I built along with a database.This application contains all the logic needed for an online rental platform, and it was a lot of fun to build. 

## Project Overview
When thinking about and designing a project, I like to think about the end user experience point of view first. For this project, the user should be able to:
- visit the DC camera rentals site
- learn about the company
- browse products
- create an account and log in
- select rental duration
- add items to cart
- edit and update the cart
- and finally, check out

From a UX perspective, the site should:
- Load quickly
- Have no errors, bugs, or slow pages
- Serve the desired business goals
- Allow the user to quickly and intuitively perform tasks such as adding to and editing the cart

Simple and straightforward, but of course, making something simple is never quick and easy.

## Wireframing and mockups

I prefer to wireframe with pen and paper and use Adobe XD or Figma to create high-fidelity mockups. For this project, though, I designed the frontend directly in code. This is something I’m working on practicing and improving. I want to be faster and more skilled at building things this way than building mockups first. I’m getting better at it - and I love using tailwindcss for this.

## The frontend tech stack

Aside from Tailwind, other tech used in this project was:
- React: my JS framework of choice for pretty much every project
- Next.js: have been really liking it lately and have built many frontend projects with it, including several static sites. I’m very comfortable with its process now and enjoy using it for many types of projects.
- A lot of dynamic components: this project was built before the switch to Next.js 14 which uses React Server Components and the App Router. Thus, it doesn’t use Server Components, but Next.js 13 does use server-side rendering so the pages are SEO-performant.

## The backend tech stack

I kept the backend simple, using Node and Express. I considered using Python as an experiment since I’ve been using it more lately, but went with Node as it works well as a backend with JS and React. 

Because I wanted to integrate authentication with JWT, this required incorporating JWT into many of the API endpoints. I got the hang of this quickly and was able to build auth checks into the backend functions where needed.

The backend ended up being over 700 lines of code, so I considered it good practice in writing API endpoints in Node.

## The database

I chose SQLite as the database management system. It is easy to use and setup, perfect for a small application like this one.

A relational structure was the right choice for this app’s data management, and I was able to keep the db structure pretty simple - tables for users, equipment, reservations, favorites, and cart. 

Foreign keys played a major role here - for example, the reservations table uses them to link the equipment and users databases. The cart and cart_items tables work in a similar way. The server queries make use of inner joins often to utilize this data schema.

## Known Issues
- Currently the app does not process payments as part of the checkout process.
- Currently only runs locally. I plan to deploy it to a web server in the future.
- There are a few issues with the date picker I would like to tighten up. It works, but a few edge cases need to be accounted for.
- When adding to cart, the Nav doesn't update the Cart count until the next page load. I plan to build out a solution to use the Context API to keep track of the cart, which would solve this issue.
- Auth token expires after 1hr, but the app doesn't immediately log the user out. I would like to implement this but am still thinking on the most elegant way to do it.

## Lessons Learned
- Importance of troubleshooting well. I spent a lot of time debugging, and this taught me the importance of thinking abuot my process and having a specific algorithm and way of going about the troubleshooting process.
- Underestimating the amount of time it takes to build a feature. For example, when I set out to build the favorites feature, I estimated 1hr for it, but it took me almost 6. On the other hand, once I developed a strong mental model for how to implement a certain query, reusing that model or design pattern elsewhere in the app was much quicker (a good example was using the user's JWT token to get the user ID and corresponding data). 

## Concepts practiced
- **JWT authentication**. Creating a user account, logging user in and out with JWTs. Also, the API endpoints don't need the user's ID included in the req url. They look it up using the token to get the user's ID and pass that to whatever SQL query is needed for that particular endpoint. 
- **React strict mode**. Hadn't used this too much previously. The main thing to note here is that in Strict Mode, React renders each component twice instead of once. This threw me off at first (why am I seeing two identical console.logs?) but this was good experience for future work in React.
- **Component-based architcture** for modular, reusable, and scalable UI. Anytime I wrote the same code or copy/pasted anything, I thought about how I could abstract it. I'm particularly proud of how the Account page looks - it's just 22 lines including comments, almost fully abstracted into custom components.
- **React hooks**. I used useEffect and useState a lot, as usual for me. But I also got more familiar with Context, with its Provider component and useContext hook. In the future, one way this app can be improved is by integrating the app's Context state more tightly with the SQL backend - which can be done via the updateContext function in the main createContext file.
- **NextJS router**. Specifically, using the useRouter hook to get the url param for the single product page.
- Creating API routes using Node.js backend. This was very new for me but this project provided extensive practice with all 4 CRUD types.
- **Sqlite database**. Making SQL queries in API endpoint functions and manipulating the data was a lot of fun. The Cart query and the Reservations query both get a little crazy, accessing several tables with several inner joins. Although this was only implemented locally, a future step can be to deploy this to something like AWS, Google Cloud, or DigitalOcean. 


Building a Photography Equipment Rental Platform: A Case Study


If you’ve spent any amount of time around the frontend development space in the last 10 years, you’re likely familiar with jQuery. 

For many, including myself, it was our first foray into the world of JavaScript after dabbling in HTML/CSS. 

I remember jQuery was the answer when I wanted to hack unnecessary frontend embellishments onto my early Wordpress sites. Those were the days…. 

## Still going strong

Released in 2006, it’s been a highly popular framework for almost 20 years now. But is it still relevant in the age of React, Angular and SPAs?

The answer is a resounding yes. In the [Stack Overflow 2023 Developer Survey](https://survey.stackoverflow.co/2023/), it sat among the top JS frameworks, beating out many popular and modern frameworks and libraries like Next, Svelte, Angular, and Vue. 

This alone shows that it’s still a major player in the space.

## Why jQuery?

jQuery’s strengths from 15 years ago are the same today. It’s excellent for quick DOM traversal, event handling, and UI modification.

To illustrate how efficient jQuery can be for developer experience, consider the following vanilla JS example:

```jsx
document.querySelectorAll('.myClass').forEach(function(el) {
  el.classList.add('anotherClass');
});
```

Pretty simple. But in jQuery, it’s barely one line:

```jsx
$('.myClass').addClass('anotherClass');
```

There are many more examples of efficiency and dev experience, but that’s not the only advantage of it.

The fact is, there are millions of projects right now that use jQuery, and often, for continued work, it’s simply most efficient to continue development in jQuery.

Combined with its excellent cross-browser support and commonly-cached CDN ubiquity, its advantages are still as strong as ever today.

A quick search reveals many major companies still using jQuery as part of their stack. Thus, learning it is definitely worthwhile, although for those new to the frontend world I always recommend learning vanilla JS deeply before moving on to frameworks and libraries.

And with the recent release of jQuery 4.0, moving to ES modules and adding formData support, it’s continuing to be supported and improved, ensuring it will remain a major player in the coming years.

## Downsides of jQuery

Of course, many new frameworks and libraries have arisen in recent years. Many of these, such as SolidJS, rival the performance of pure vanilla JS. They also offer a additional abstractions and design patterns that better support scaled front-end and full-stack enterprise applications.

In addition, vanilla JS has improved in many of the areas that jQuery once offered a more significant improvement - so the difference is smaller in many areas.

## Should I learn it?

My answer is yes, BUT learn vanilla JS first. If you’re thinking of taking a course or building a project with jQuery, my first question would be - could you learn vanilla JS better if you stuck to that? And instead took a vanilla JS course or built your project with it alone.

However, for more seasoned developers or those looking to build a product - I think this is where jQuery would have some more consideration. You’d want to weigh it against other options such as React, Angular, and others, of course. Depending on the needs of the project, it could be the right choice.


Recent Articles.

Case Studies: Refactoring for Performance in React

Authentication in React: Two Approaches

Building a Photography Equipment Rental Platform: A Case Study

jQuery in 2024: Still in Your Toolkit?