DEV Community: padmajothi Athimoolam

Enforcing Immutability in Singleton Pattern with Object.freeze()

padmajothi Athimoolam — Wed, 29 Jan 2025 18:05:43 +0000

Using Object.freeze() in a Singleton design pattern ensures that the singleton instance cannot be modified once it has been created. This can be useful when you want to prevent changes to the Singleton instance, making sure it remains immutable and its properties are protected from being altered after initialization.

Example: Using Object.freeze() in a Singleton Pattern
Here’s how you can implement the Singleton pattern with Object.freeze():

** Singleton Design Pattern with Object.freeze()**

class ThemeManager {
    constructor() {
        if(ThemeManager.instance) {
            this.theme = localStorage.getItem('theme') || 'light';
            ThemeManager.instance = this;
        }

        return ThemeManager.instance;
    }

    setTheme(newTheme) {
        this.theme = newTheme;
        localStorage.setItem('theme', newTheme);
    }

    getTheme() {
        return this.theme
    }
 }

 const themeManager = new ThemeManager(); // Create an instance
 Object.freeze(this); // Freeze the instance to make it immutable
 export default themeManager; // Export the instance

Object.freeze(): The Object.freeze(this) call makes the instance immutable after it's created, meaning you cannot add new properties, modify existing properties, or change the state of the themeManager instance.If you try to modify themeManager after freezing, it won't allow changes, providing a layer of protection.It will throw error

Uncaught TypeError: Cannot add property theme, object is not extensible

Why Use Object.freeze()?

Immutability: Once an instance is created, it can't be modified. This is particularly useful when you want to prevent accidental changes to the Singleton object’s properties and methods.

Enforce Consistency: You ensure that the Singleton instance is always consistent and protected against any changes that might break the application logic.

What is the Singleton Pattern?

padmajothi Athimoolam — Wed, 29 Jan 2025 17:52:34 +0000

What is the Singleton Pattern?

The Singleton Pattern ensures that a class has only one instance and provides a global point of access to it. The pattern is often used for managing resources like API clients, caching, or configuration that needs to be shared across various parts of the application.

In the context of React, we usually want to implement a singleton for:

Global state management (e.g., settings, themes).
API client or data management (e.g., fetching data, caching).
Logging or analytics service that needs to track events consistently.

How to Implement a Singleton Pattern in React

Example: Singleton for Managing Theme (Dark Mode Toggle)

Let's say you have a website that allows users to toggle between a light and dark theme. The Singleton design pattern can help manage the theme preference across the app to ensure that the same instance of the theme is applied everywhere.

1. Create the Singleton Class for Theme Management
This class will handle getting and setting the theme, and ensure there's only one instance used throughout the app.

// themeManager.js

class ThemeManager {
    constructor() {
        if(ThemeManager.instance) {
            this.theme = localStorage.getItem('theme') || 'light';
            ThemeManager.instance = this;
        }

        return ThemeManager.instance;
    }

    setTheme(newTheme) {
        this.theme = newTheme;
        localStorage.setItem('theme', newTheme);
    }

    getTheme() {
        return this.theme
    }
 }

 const themeManager = new ThemeManager(); // Create an instance
 export default themeManager; // Export the instance

2. Using the Singleton in Your React App
Now, you can use this ThemeManager Singleton in your React components to apply and toggle the theme.

App.js

import { useEffect, useState } from 'react';
import themeManager from './themeManager';
import './app.css';

const App = () => {
  const [theme, setTheme ] = useState(themeManager.getTheme());

  useEffect(() => {
    document.body.className = theme;
  }, [theme]);

  const toggleTheme = () => {
    const newTheme = theme === 'light' ? 'dark' : 'light';
    themeManager.setTheme(newTheme);
    setTheme(newTheme);
  };

  return (
    <div>
      <h1>SingleTone pattern with Theme Manager</h1>
      <button onClick={toggleTheme}> Toggle to { theme === 'light' ? 'dark' : 'light' } Mode
      </button>     
    </div>
  )
}
export default App;

3. Apply the Styles for Themes
Now you can define some CSS to switch between light and dark themes.

/* styles.css */
body.light {
  background-color: white;
  color: black;
}

body.dark {
  background-color: black;
  color: white;
}

The Singleton (themeManager) ensures there’s only one instance of the theme across the entire application.
When the user toggles the theme, it’s updated both in localStorage (so it persists on page reloads) and in the Singleton instance.
The React component (in this case, App.js) listens for theme changes, and any other component can also access the same Singleton to get or update the theme.

Benefits of Using Singleton Here:

_Global State Consistency: _The theme state is consistent throughout the app, and any component can access or modify it.

Persistent Theme: By using localStorage, the theme persists across page reloads, and you ensure the same theme is used after the app is restarted.

_Single Source of Truth: _The Singleton provides a single point of truth for the theme, ensuring that no other part of the app creates its own instance of the theme or overrides the global theme state.

Check out my project on Singleton Theme manager

Reusable Code in React

padmajothi Athimoolam — Tue, 14 Jan 2025 18:51:39 +0000

When working with React applications, especially in larger projects like an e-commerce app, you'll often encounter situations where components share similar functionality or structure but differ in logic or JSX. To improve code maintainability, avoid repetition, and ensure reusability, we can break down these scenarios and discuss possible solutions with code samples.

1. Problem: Two Components Have Different Logic, but Nearly Identical JSX

Scenario:
You have two components that look nearly identical (i.e., similar JSX structure), but their logic is different. For example, a component that displays a product list and a component that displays featured products. They share a similar layout but have different logic for fetching the products.

Solution:
In this case, you can extract the shared JSX into a reusable component and allow each parent component to pass its unique logic as props (such as the data to display or specific actions to trigger).

Example:

// ProductCard.js - Shared JSX component
import React from 'react';

const ProductCard = ({ product, onAddToCart }) => {
  return (
    <div className="product-card">
      <img src={product.image} alt={product.name} />
      <h3>{product.name}</h3>
      <p>{product.description}</p>
      <p>${product.price}</p>
      <button onClick={() => onAddToCart(product)}>Add to Cart</button>
    </div>
  );
};

export default ProductCard;

Now, let's create two parent components: ProductList and FeaturedProducts, which have different logic but reuse ProductCard for their JSX.

// ProductList.js - Fetching all products
import React, { useEffect, useState } from 'react';
import ProductCard from './ProductCard';

const ProductList = () => {
  const [products, setProducts] = useState([]);

  useEffect(() => {
    // Fetch all products (this is just an example)
    fetch('/api/products')
      .then((res) => res.json())
      .then((data) => setProducts(data));
  }, []);

  const handleAddToCart = (product) => {
    // Add to cart logic
    console.log('Added to cart:', product.name);
  };

  return (
    <div>
      <h2>All Products</h2>
      {products.map((product) => (
        <ProductCard key={product.id} product={product} onAddToCart={handleAddToCart} />
      ))}
    </div>
  );
};

export default ProductList;

FeaturedProducts.js

// FeaturedProducts.js - Fetching only featured products
import React, { useEffect, useState } from 'react';
import ProductCard from './ProductCard';

const FeaturedProducts = () => {
  const [featuredProducts, setFeaturedProducts] = useState([]);

  useEffect(() => {
    // Fetch featured products (this is just an example)
    fetch('/api/featured-products')
      .then((res) => res.json())
      .then((data) => setFeaturedProducts(data));
  }, []);

  const handleAddToCart = (product) => {
    // Add to cart logic
    console.log('Featured Product added to cart:', product.name);
  };

  return (
    <div>
      <h2>Featured Products</h2>
      {featuredProducts.map((product) => (
        <ProductCard key={product.id} product={product} onAddToCart={handleAddToCart} />
      ))}
    </div>
  );
};

export default FeaturedProducts;

Both components (ProductList and FeaturedProducts) share similar JSX but have different logic for fetching products. By using a reusable ProductCard component, you avoid code duplication.

2. Two Components Have the Same Logic, but Different JSX

Scenario:
You have two components that share the same logic (e.g., fetching products), but they display the data in different layouts. For example, a grid view for products and a list view for products.

Solution:
In this case, you can extract the common logic into a custom hook or a shared context and pass the layout-specific JSX (or rendering logic) as props to a reusable presentational component.

Example:

// useProducts.js - Shared hook for fetching products
import { useState, useEffect } from 'react';

const useProducts = () => {
  const [products, setProducts] = useState([]);

  useEffect(() => {
    // Fetch products
    fetch('/api/products')
      .then((res) => res.json())
      .then((data) => setProducts(data));
  }, []);

  return products;
};

export default useProducts;

Now, we can create two components that share the logic but have different rendering (layout) styles.

// GridView.js - Grid layout for products
import React from 'react';
import useProducts from './useProducts';
import ProductCard from './ProductCard';

const GridView = () => {
  const products = useProducts();

  return (
    <div className="product-grid">
      {products.map((product) => (
        <ProductCard key={product.id} product={product} />
      ))}
    </div>
  );
};

export default GridView;

ListView.js

// ListView.js - List layout for products
import React from 'react';
import useProducts from './useProducts';
import ProductCard from './ProductCard';

const ListView = () => {
  const products = useProducts();

  return (
    <div className="product-list">
      {products.map((product) => (
        <ProductCard key={product.id} product={product} />
      ))}
    </div>
  );
};

export default ListView;

Both GridView and ListView share the same logic for fetching products (via the useProducts hook) but have different layouts. By separating the logic (with a custom hook) and reusing the ProductCard component, you maintain clean code while supporting different visual layouts.

3. Problem: Two Components Have Similar Logic and JSX

Scenario:
You have two components with both similar logic and nearly identical JSX. For example, you have a product details page and a checkout page that both require displaying a list of items in a cart, and the logic for adding/removing items is almost identical.

Solution:
In this case, you can abstract the shared code into a reusable component and wrap it in a higher-order component (HOC) or a shared state management solution (like Context API) to further eliminate redundancy.

Example:

// CartItem.js - Shared component for displaying a cart item
import React from 'react';

const CartItem = ({ product, onRemove }) => (
  <div className="cart-item">
    <h3>{product.name}</h3>
    <p>${product.price}</p>
    <button onClick={() => onRemove(product.id)}>Remove</button>
  </div>
);

export default CartItem;

Now, we can create two components: CartPage and CheckoutPage, which use the shared CartItem component.

// CartPage.js - Cart page showing cart items
import React, { useState } from 'react';
import CartItem from './CartItem';

const CartPage = () => {
  const [cartItems, setCartItems] = useState([
    { id: 1, name: 'Laptop', price: 999 },
    { id: 2, name: 'Smartphone', price: 599 },
  ]);

  const handleRemoveItem = (id) => {
    setCartItems(cartItems.filter((item) => item.id !== id));
  };

  return (
    <div>
      <h2>Your Cart</h2>
      {cartItems.map((item) => (
        <CartItem key={item.id} product={item} onRemove={handleRemoveItem} />
      ))}
    </div>
  );
};

export default CartPage;

checkoutPage.js

// CheckoutPage.js - Checkout page showing cart items (same logic)
import React, { useState } from 'react';
import CartItem from './CartItem';

const CheckoutPage = () => {
  const [cartItems, setCartItems] = useState([
    { id: 1, name: 'Laptop', price: 999 },
    { id: 2, name: 'Smartphone', price: 599 },
  ]);

  const handleRemoveItem = (id) => {
    setCartItems(cartItems.filter((item) => item.id !== id));
  };

  return (
    <div>
      <h2>Checkout</h2>
      {cartItems.map((item) => (
        <CartItem key={item.id} product={item} onRemove={handleRemoveItem} />
      ))}

    </div>
  );
};

export default CheckoutPage;

Both CartPage and CheckoutPage share the same logic for displaying and removing items from the cart. By using a shared CartItem component, you can eliminate redundancy and keep the code clean, even when the JSX structure and logic are similar.

By following these strategies—whether it’s breaking down logic into custom hooks, creating shared components, or utilizing context—React developers can significantly reduce redundancy and build applications that are both easier to maintain and extend.

Comparing Jest, React Testing Library, and Playwright: Testing Approaches for React Applications

padmajothi Athimoolam — Mon, 28 Oct 2024 15:07:34 +0000

1. Jest
Purpose: Jest is a testing framework for JavaScript, commonly used for unit and integration testing.

Usage in React:

It provides a simple way to run tests, mock functions, and perform assertions.
Typically used for testing individual components and utility functions.

Example:

import { render, screen } from '@testing-library/react';
import MyComponent from './MyComponent';

test('renders a message', () => {
  render(<MyComponent />);
  const linkElement = screen.getByText(/hello world/i);
  expect(linkElement).toBeInTheDocument();
});

2. React Testing Library (RTL)
Purpose: RTL is a testing utility specifically designed for testing React components.

Usage in React:

Focuses on testing components in a way that resembles how users interact with them.
Encourages best practices, like querying by text rather than implementation details.
Works seamlessly with Jest.

Example:

import { render, screen } from '@testing-library/react';
import MyComponent from './MyComponent';

test('displays a message to the user', () => {
  render(<MyComponent />);
  expect(screen.getByRole('heading')).toHaveTextContent('Hello World');
});

3. Playwright
Purpose: Playwright is an end-to-end testing framework used for testing web applications.

Usage in React:

Tests the entire application flow in a browser, simulating user interactions.

Useful for testing scenarios where multiple components and pages interact, such as form submissions, navigation, and API calls.

Example:

const { test, expect } = require('@playwright/test');

test('homepage has a welcome message', async ({ page }) => {
  await page.goto('http://localhost:3000');
  const welcomeMessage = await page.textContent('h1');
  expect(welcomeMessage).toBe('Welcome to My App');
});

Summary of Differences
Scope:

Jest: Unit and integration testing (individual components and functions).

React Testing Library: Component testing focusing on user interactions.

Playwright: End-to-end testing simulating user behavior in a real browser.

Approach:

Jest: Uses assertions to validate outcomes.

React Testing Library: Encourages testing as users would interact with the app.

Playwright: Interacts with the application like a real user, covering all components and their integrations.

Execution:

Jest: Runs tests in a Node.js environment.

React Testing Library: Runs with Jest or another framework but tests components rendered in a simulated DOM.

Playwright: Runs tests in real browsers, checking for functionality across multiple environments.

Handling Environment Variables in Vite

padmajothi Athimoolam — Mon, 21 Oct 2024 21:58:17 +0000

In modern web development, managing sensitive data such as API keys, database credentials, and various configurations for different environments is essential. Storing these variables directly in code can pose security risks and complicate deployment. Vite, a modern front-end build tool, provides a straightforward way to manage environment variables through .env files.

What is a .env File?

A .env file is a simple configuration file used to define environment-specific variables. These variables can be accessed within your application while remaining separate from the source code. This practice allows for easy management of different environments—development, staging, and production—without hardcoding sensitive data.

Environment Variables in Vite:

Vite comes with built-in support for environment variables, making it easier to inject different values based on the current environment. Here’s how Vite handles environment variables:

Global Variables: Vite injects environment variables at build time.
Prefixed Variables: Only variables prefixed with VITE_ are exposed to the client-side JavaScript code for security reasons. Any variables not prefixed this way won’t be accessible in the browser.

Example of a Vite environment variable:

VITE_API_URL=https://api.example.com

Setting Up .env Files in Vite
Vite supports multiple .env files, allowing you to define environment variables for specific environments. Here’s a typical setup:

.env: Default file for environment variables shared across all environments.
.env.development: Variables specific to the development environment.
.env.production: Variables specific to the production environment.

Example .env File:

VITE_API_URL=https://api.example.com
VITE_APP_NAME=MyViteApp

Example .env.development File:

VITE_API_URL=http://localhost:3000
VITE_DEBUG_MODE=true

Example .env.production File:

VITE_API_URL=https://api.production.com
VITE_DEBUG_MODE=false

Accessing Environment Variables in Vite

To access environment variables inside your Vite project, use the import.meta.env object.

console.log(import.meta.env.VITE_API_URL); // Outputs the value of VITE_API_URL

Vite automatically replaces import.meta.env values during the build process based on the current environment.

Managing Multiple Environments:

Vite’s .env files can be customized for different environments like development, staging, and production. Depending on which environment you're in, Vite will load the appropriate .env file:

Running vite loads the .env.development file.
Running vite build loads the .env.production file.
Running in a specific environment:

vite --mode staging

Debugging Environment Variables:

If you’re having issues with environment variables not working as expected, check the following:

Variable Prefix: Ensure all client-side variables have the VITE_ prefix, as Vite ignores variables without this prefix.
Env Loading Order: Make sure .env and environment-specific files are in the project root and named correctly.
Check Build Process: Use console.log(import.meta.env) to see all available environment variables during development.

Conclusion::

Vite’s built-in support for environment variables through .env files makes it easy to manage configurations across different environments.

Transpiler vs Polyfills

padmajothi Athimoolam — Mon, 07 Oct 2024 23:59:13 +0000

In modern web development, maintaining compatiablity across different browsers and environments is a crucial challenge. Two important tools that help developers overcome this issue are transpilers and polyfills. Both serve the purpose of making code work across different platforms, they operate in distinct ways.

What is Transpilers

A transpiler is a tool that converts code written in one language ot syntax to another language or syntax. Specially, in the context of Javascript, transpilers convert modern Javascript (ES6+) into older versions of Javascript (like ES5) that can be understood by older browsers on environments.

key points:

- Syntax-Level Conversion: A transpiler converts code by transforming newer syntax and features( e.g. let,const, arrow functions) into equivalent constructs in older version. It ensures the same code runs across different environments.

E.g. Babel - Converts modern ES6+ code into ES5.
TypeScript Compiler - Converts Typescript into plain JavaScript.

ES6 code

let greet = () => console.log("Hello World!");

A transpiler would convert it to ES5, looks like :

var greet = function () {
console.log("Hello World!");

What is Polyfills?

A Polyfill is a piece of code, that provides missing functionality in older browsers or environments.It "fills in" the gaps where. a certain feature is not natively supported.

key points:

-Feature Level Emulation: Unlike a transpiler, which transforms code syntax, a polyfill implements missing features.

Polyfills are added at runtime and do not modify the source code.

E.g - includes polyfills

For browsers that don't support the Array.prototype.includes method, a polyfill can be implemented like this:

if(!Array.prototype.includes) {
Array.prototype.includes = 
  function(searchElement) {
    return this.indexOf(searchElement) !== -1
  }
}

Key Difference

By using transpiler, we can ensure the code is compatible with older environments, while polyfills allow to add missing functionality. Together they allow developers to write modern, efficient code without worrying about breaking support for older platforms.

The Power of Redux Toolkit's createSlice

padmajothi Athimoolam — Thu, 26 Sep 2024 15:37:27 +0000

createSlice is one of the most powerful and essential features of Redux Toolkit (RTK). It simplifies the process of writing Redux logic by reducing boilerplate and offering a cleaner, more maintainable code structure. This article will explore what createSlice is, how it works, and why it's a game-changer for Redux development.

What is createSlice?
createSlice is a utility in Redux Toolkit that allows developers to define a slice of the Redux state in a highly efficient way. It combines the logic for actions and reducers into a single, concise format, automating many tedious tasks such as action creation and action type definition.

Key Features of createSlice
Simplified Reducer Logic: With createSlice, you no longer need to write action types and action creators manually.
Automatic Action Creation: It generates action creators automatically based on the defined reducer methods.
Built-in Immutability with Immer: Redux Toolkit uses Immer internally, which allows writing "mutating" code that adheres to Redux’s immutability principles.
Combines Reducers and Actions: Reduces the need for separate files for actions and reducers, allowing you to keep related logic together.

How to Use createSlice
The core idea of createSlice is that it allows you to create a "slice" of your application's state, and you can define all related logic (state, reducers, actions) within it.

1. Defining a Slice
A slice includes three main things:

Name: The name of the slice, used as the action type prefix.
Initial state: The starting state of the slice.
Reducers: Functions that handle how the state is updated in response to actions.

import { createSlice } from '@reduxjs/toolkit';

const counterSlice = createSlice({
  name: 'counter',
  initialState: {
    value: 0,
  },
  reducers: {
    increment: (state) => {
      state.value += 1; // Immer allows "mutating" the state directly
    },
    decrement: (state) => {
      state.value -= 1;
    },
    incrementByAmount: (state, action) => {
      state.value += action.payload;
    },
  },
});

export const { increment, decrement, incrementByAmount } = counterSlice.actions;
export default counterSlice.reducer;

2. Reducer Logic Simplified
In traditional Redux, reducers require creating a new copy of the state every time it is updated, making the code more verbose. With createSlice can directly "mutate" the state.

3. Automatic Action Creators
When you define reducers in createSlice, Redux Toolkit automatically generates corresponding action creators. For example, based on the code above:

The increment reducer generates the increment() action.
The decrement reducer generates the decrement() action.
The incrementByAmount reducer generates the incrementByAmount(payload) action, where payload is passed as an argument.

dispatch(increment());         // Dispatches increment action
dispatch(decrement());         // Dispatches decrement action
dispatch(incrementByAmount(5)); // Dispatches action with payload of 5

Benefits of Using createSlice

Reduced Boilerplate: One of the main pain points with traditional Redux was the amount of boilerplate code needed for action types, action creators, and reducers. createSlice drastically reduces this by co-locating these in one function.

Immutability without Complexity: Immer is baked into Redux Toolkit, so you can "mutate" state directly in your reducers, but the actual updates are done immutably under the hood. This leads to simpler and cleaner code without the risk of accidentally mutating state.

Automatic Action Types: Each reducer you define in createSlice automatically generates an action type that includes the slice name, ensuring no naming collisions and making it easier to manage larger applications.

Easier Debugging: Redux DevTools and time-travel debugging work seamlessly with createSlice, so you can inspect every action and state change efficiently.

Conclusion

createSlice in Redux Toolkit is a game-changer for state management in React. By combining reducers, actions, and initial state into one streamlined function, it simplifies the Redux development process, allowing you to focus on building your application without worrying about boilerplate code. Its integration with Immer ensures that state updates remain immutable while providing a natural, intuitive API for handling complex state logic. Whether you're managing simple counters or complex arrays of objects, createSlice makes state management in Redux more efficient and maintainable.

Simplifying Fetching Data with React Query: Replacing useEffect

padmajothi Athimoolam — Fri, 20 Sep 2024 15:15:54 +0000

React Query

React Query's core functionality revolves around fetching and caching data from an API and handling state management, while search engines like Google allow us to query and retrieve relevant information from an extensive database. In this blog, we'll explore how React Query can replace useEffect for data fetching, leading to cleaner and more maintainable code.

Understanding React Query

React Query is a data-fetching library that simplifies the process of managing server state in React applications. It provides hooks for fetching, caching, and syncing server data without the complexity that often comes with useEffect.

Why Replace useEffect?

While useEffect is useful for managing side effects like data fetching, it can lead to complicated code structures. You often find yourself writing multiple effects for different data dependencies, handling loading states, and managing cleanup functions. This can quickly become messy

Benefits of Using React Query

Simplified Data Fetching: React Query abstracts away the complexities of data fetching and state management.

Automatic Caching: It automatically caches fetched data, reducing unnecessary requests.

Background Updates: Data can be kept fresh in the background, ensuring users see the most up-to-date information.

Built-in Loading and Error States: React Query provides loading and error states out of the box, making UI management easier.

Replacing useEffect with React Query

Let’s consider an example where we fetch user data from an API. Here’s how you might traditionally use useEffect:

import React, { useEffect, useState } from 'react';

const UserProfile = () => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await fetch('https://api.example.com/user');
        if (!response.ok) throw new Error('Network response was not ok');
        const data = await response.json();
        setUser(data);
      } catch (error) {
        setError(error);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, []);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return <div>{user.name}</div>;
};

Now, let’s see how we can refactor this code using React Query:

import React from 'react';
import { useQuery } from 'react-query';

const fetchUser = async () => {
  const response = await fetch('https://api.example.com/user');
  if (!response.ok) throw new Error('Network response was not ok');
  return response.json();
};

const UserProfile = () => {
  const { data: user, isLoading, isError, error } = useQuery('user', fetchUser);

  if (isLoading) return <div>Loading...</div>;
  if (isError) return <div>Error: {error.message}</div>;

  return <div>{user.name}</div>;
};

useQuery Hook: This hook replaces useEffect for data fetching. It accepts a unique key (in this case, 'user') and a function to fetch the data.

Loading and Error Handling: Instead of managing loading and error states manually, React Query provides isLoading, isError, and error directly from the useQuery response.

_Cleaner Code: _The resulting code is simpler and easier to read. You don’t have to worry about cleanup or dependency arrays.

Conclusion

React Query significantly streamlines the process of managing server state in React applications. By replacing useEffect with React Query’s powerful hooks, you can simplify your code, improve readability, and enhance user experience. If you haven’t yet tried React Query, now is a great time to start exploring its capabilities!

React Code Review Essentials: A Detailed Checklist for Developers

padmajothi Athimoolam — Mon, 09 Sep 2024 16:08:35 +0000

1. Overview

-README: Ensure the project has a Readme file with instructions on how to run locally and other useful information.

-Error-Free code: Verify that the code runs without errors.
-Functionality: Confirm that the application looks good on mobile devices.
-Responsiveness: Check if the application looks good on mobile devices
-Linting: Verify if the codebase uses eslint.
-.gitignore: Ensure no dist files, editor/IDE files are checked in.

Tip: The Toptal Gitignore generator helps you create customized .gitignore files to exclude unnecessary or sensitive files from being tracked by Git based on your project's technology stack.

2. Testing

Unit tests: Confirm there are unit tests for crucial parts of the codebase.

3. Naming:

Consistency: Ensure filenames, variables, functions, and modules have consistent casing and descriptive names.

4. Code quality:

Code duplication: Look for blocks of code that can refactored to reduce duplication.
Simplify code: Simplify overly complex code.
Unused code: Remove unused or unreachable code.
Commented-out code: Delete commented-out code
Console Logs: Remove console.log statements unless necessary.
Comments: Remove unnecessary comments that describe "how" and add comments where needed that describe "why".

5. ES6+ features

Spread operator: Utilize the spread operator where applicable. -** Destructuring**: use destructuring for arrays and objects.
Var or Let/Const: Replace var with let or const
Arrow functions: Use arrow functions consistently.
Lodash/ES6: Ensure consistency in using lodash, ES6 or older Javascript for data transformation.

6. React Best practices:

Minimize Render logic: Move logic out of render method into helper methods, container components, or Redux actions.
Side effects: Move code with side effects( eg. ajax calls) out of render methods.
Components size: split up larger components to reduce duplication and adhere to the single responsibility principle.
Destructuring Props: Destructure props in Es6 components.
Functional components: Use functional components for stateless components
Immutable Props: Ensure props are not modified within components.

7. Redux:

State Mutations: Verify the reducers do not mutate the state.

8. Component Design:

Component size: Keep components small and break them down into child components if necessary.
JSX size: Ensure JSX markup is no more than 50 lines,
Function comments - Add comments describing what each function does.
Linter errors: Ensure code id free of linter errors.
React warnings: Resolve any react warnings, such and missing key props in array.
DRY principle: Avoid repeating code, ensure code is reusable.
Code Pattens: Adhere to existing code patterns and naming conventions
Usused props: Remove any unused props
Styling: Prefer using common styling files over inline styles.
Constants and Enums: Avoid hardcoded values. Use constants and group similar values under Enum.
Interfaces and Types: Ensure proper use of interfaces and types, Extending them where required.

9. API and Async Handling"

Service Layer: create a service layer for API calls.
promises/Async/Await: Use Promises or async/await for asynchronous operations and handle API rejections.
Avoid infinite call inside loops.
Exception Handling: Implement proper exception handling and resource cleanup.
Timers: Unregister timers in clean-up effects if registered during mounting.

10. Additional considerations:

Image Alt Text: Ensure all images have appropriate alt attributes.
Git commit messages: Use small and understandable commit messages.
NPM package: Check for new npm packages and avoid functionality duplicates.
Imports: Ensure imports to avoid bundling unused library parts.
Translations: Verify that new text areas are translated if translations are used.
Typescript: Fix any missing or invalid types, avoid any types unless necessary.
Boolean naming: Use prefixes like is/are/should for boolean variables.
Function names: Ensure functions declare their purpose clearly and name them according to their action.
Hardcoded values: Avoid hardcoded names, paths and values.
Backward compatibility: Ensure backward compatibility in props and method parameters.
Form Validation: Check for form validation and proper handling of errors.
Async Methods: Optimize async methods for parallel execution where possible.

Use this checklist as a guide to review and improve React code ensuring high-quality, maintainable, and performant applications.

Understanding error={!!error} in React: What Does it Mean?

padmajothi Athimoolam — Tue, 27 Aug 2024 21:29:42 +0000

In React applications, handling and displaying errors gracefully is crucial for creating a user-friendly experience. One common pattern is the usage of error={!!error}. This pattern leverages Javascript's type coercion to ensure a boolean value is used for conditional rendering or logic. But what does it really mean, and why is it used?

The Double Exclamation Mark(!!) Operator

The !! operator is used to convert a value to a boolean. It's a shorthand for ensuring that a value is either true or false, depending on truthiness. Here's a breakdown of how it works.

*1. Single Exclamation Mark (!): *
When used once,! it converts a value to its boolean negation. For example:

!true   //false
!false  //true
!0      //true ( 0 is falsy)
!1      //false ( 1 is truthy)

2. Double Exclamation Mark(!!)
Applying ! twice converts any value to boolean:

!!true    //true
!!false  //false
!!0      //false
!!1      //true
!!'hello' //true ( non-empty strings are truthy)
!!''     //false ( empty strings are falsy)

Essentially !! forces any value to be explicitly true or false.

why use !! in React?

In React, you might encounter !! when dealing with conditional rendering or props where a boolean value is required.

Ensures Boolean Values: React components often expect boolean values for certain props such as error, disabled or visible. Using !! guarantees that these props receive a boolean value, preventing unexpected behavior. - Consistency in Conditional Rendering: When using conditional rendering, it's crucial to ensure the condition evaluates to a boolean. This avoids errors and ensures consistent rendering logic.

Practical Examples in React

Example 1: Conditional Rendering

consider a scenario where you want to display an error message only if an error exists:

import React from 'react';

const ErrorMessage = ({ error }) => (
  <div>
    {error && <p style={{ color: 'red' }}>{error}</p>}
  </div>
);

In this example, error can be a string or null/ undefined. If error is a non empty string , the message will be displayed. If error is falsy (null or undefined), the message won't be rendered.

However, if error is always a boolean or if you want to ensure that error is explicitly a boolean you can use !!.

import React from 'react';

const ErrorMessage = ({ error }) => (
  <div>
    {!!error && <p style={{ color: 'red' }}>An error occurred</p>}
  </div>
);

Here, !!error ensures that the expression evaluates to true or false, making the rendering logic more predictable.

Example 2: Handling Props

When passing prop that expects a boolean, !! ensures the correct type:

import React from 'react';

const SubmitButton = ({ isDisabled }) => (
  <button disabled={!!isDisabled}>Submit</button>
);

In this case, !!isDisabled guarantees that the disabled attribute will receive a boolean value, even if isDisabled is undefined, null or any other falsy value.

*Common use cases *

Form Validation: When handling form validation, using !! can ensure that validation states (like hasErrors) are properly converted to booleans for rendering or logic checks
Dynamic classes: In class names or style conditions, !! can be used to ensure boolean values for applying conditional styles or classes.

const buttonClass = `btn ${!!isPrimary ? 'btn-primary' : 'btn-secondary'}`;

Conclusion:

The !! operator is used for ensuring values are explicitly converted to booleans in Javascript and React applications. It can prevent potential bugs and ensure your components behave as expected. This is particularly useful for conditional rendering and managing props where boolean values are required.